Sécurité SSH : connexion par clé et fail2ban

Dès qu'un serveur de jeu, un VPS ou n'importe quelle machine Linux est en ligne, la sécurité SSH devient votre ligne de défense la plus critique. En effet, la première chose que tentent les attaquants est d'envoyer des centaines de combinaisons identifiant–mot de passe sur le port 22 ouvert à l'aide d'outils automatisés. Dans ce guide, je détaille la mise en place de la connexion par clé, la désactivation complète de l'authentification par mot de passe, le changement de port et le blocage automatique des attaques par force brute avec fail2ban — étape par étape, avec de vraies commandes fonctionnelles.

Pourquoi un mot de passe seul ne suffit pas

Les mots de passe peuvent être devinés, fuités et restent vulnérables aux attaques par dictionnaire. Si vous consultez les journaux du serveur (sudo journalctl -u ssh ou /var/log/auth.log), vous verrez des centaines de tentatives de connexion échouées provenant d'IP inconnues. Une clé SSH, en revanche, est une paire cryptographique asymétrique pratiquement impossible à deviner : la clé privée reste chez vous, tandis que la clé publique est copiée sur le serveur. Le serveur n'autorise que celui qui possède la clé privée correspondante. Correctement configurée, la menace de force brute sur le mot de passe disparaît totalement.

1. Générer une paire de clés SSH

Sur votre propre ordinateur (pas sur le serveur), créez une clé ed25519 moderne et sûre :

ssh-keygen -t ed25519 -C "aslain@laptop"

La commande demande un chemin de fichier et une passphrase facultative. La passphrase chiffre votre clé privée sur le disque avec un mot de passe supplémentaire ; elle constitue une seconde barrière si votre ordinateur portable est volé — ne la sautez pas. Vous obtenez deux fichiers : la clé privée ~/.ssh/id_ed25519 et la clé publique ~/.ssh/id_ed25519.pub. Celle avec l'extension .pub est partageable ; ne partagez jamais celle sans extension.

2. Copier la clé publique sur le serveur

La méthode la plus simple est ssh-copy-id. Elle ajoute votre clé publique au fichier ~/.ssh/authorized_keys du serveur avec les bonnes permissions :

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@ip_serveur

Si ssh-copy-id n'est pas disponible, vous pouvez ajouter la clé manuellement. Les permissions doivent être correctes, sinon SSH ignore la clé :

ssh utilisateur@ip_serveur "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" < ~/.ssh/id_ed25519.pub

Maintenant, dans un nouveau terminal, testez si vous pouvez vous connecter sans mot de passe (avec seulement la passphrase) :

ssh utilisateur@ip_serveur

Vérifiez-le sans fermer votre session actuelle ; si la clé ne fonctionne pas, vous pouvez encore corriger l'erreur tant que la connexion par mot de passe est active.

3. Désactiver la connexion par mot de passe et root

Une fois que vous avez confirmé que la connexion par clé fonctionne, désactivez l'authentification par mot de passe. La configuration se trouve dans /etc/ssh/sshd_config. Faites une sauvegarde avant de modifier :

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Trouvez ces lignes (ajoutez-les si elles manquent) et définissez leurs valeurs :

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no

PermitRootLogin prohibit-password n'autorise root qu'avec une clé ; pour plus de sécurité, mettez no et travaillez avec un utilisateur normal et sudo. Sur certains systèmes, ces réglages peuvent être remplacés par des fichiers sous /etc/ssh/sshd_config.d/ ; vérifiez-y aussi. Testez la syntaxe avant d'appliquer, puis redémarrez le service :

sudo sshd -t
sudo systemctl restart ssh

Sur certaines distributions, le service s'appelle sshd (systemctl restart sshd). Après le redémarrage, ouvrez une nouvelle connexion sans fermer la session actuelle et confirmez à nouveau la connexion par clé.

4. Changer le port : moins de bruit, pas une solution

Déplacer SSH du port standard 22 vers un autre (par ex. 2222 ou 49222) éloigne la plupart des bots de scan automatisés de vos journaux. C'est une mesure de réduction du bruit, pas une mesure de sécurité — la vraie protection, ce sont les clés et fail2ban. Garder des journaux propres reste toutefois utile :

Port 49222

Si un pare-feu (comme UFW) tourne sur le serveur, ouvrez le nouveau port avant de redémarrer le service, sinon vous vous bloquerez vous-même :

sudo ufw allow 49222/tcp
sudo systemctl restart ssh

Vous devez désormais préciser le port lors de la connexion : ssh -p 49222 utilisateur@ip_serveur. Pour éviter de le taper à chaque fois, ajoutez un raccourci à votre fichier local ~/.ssh/config :

Host monserveur
    HostName ip_serveur
    User utilisateur
    Port 49222
    IdentityFile ~/.ssh/id_ed25519

Ensuite, ssh monserveur suffit.

5. Automatiser la protection contre la force brute avec fail2ban

Même avec les mots de passe désactivés, les bots continuent d'essayer de se connecter. fail2ban surveille les journaux et bannit temporairement, via le pare-feu, toute IP effectuant trop de tentatives échouées dans une fenêtre définie. Installation sur Debian/Ubuntu :

sudo apt update && sudo apt install fail2ban -y

Ne configurez pas directement dans jail.conf ; utilisez un fichier de surcharge jail.local afin que les mises à jour du paquet n'écrasent pas vos réglages :

sudo nano /etc/fail2ban/jail.local

Définissez-y une prison (jail) pour SSH. Si vous avez changé le port, indiquez-le sur la ligne port :

[sshd]
enabled = true
port = 49222
maxretry = 4
findtime = 10m
bantime = 1h

Ce réglage bannit une IP pendant 1 heure après 4 tentatives échouées en 10 minutes. Pour punir plus longtemps les récidivistes, vous pouvez aussi ajouter bantime.increment = true. Démarrez le service et vérifiez son état :

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

La sortie affiche le nombre et la liste des IP bannies. Si vous bannissez accidentellement une IP (par exemple la vôtre), vous pouvez la libérer manuellement :

sudo fail2ban-client set sshd unbanip 203.0.113.10

6. Quelques étapes de durcissement supplémentaires

• Contre le verrouillage hors du serveur : après toute modification critique, gardez toujours une seconde session ouverte et testez la nouvelle connexion.
• Pare-feu : avec UFW, n'ouvrez que les ports nécessaires (sudo ufw default deny incoming) et fermez tout sauf les ports de votre serveur de jeu.
• Restez à jour : exécutez régulièrement sudo apt update && sudo apt upgrade ; les failles SSH sont surtout exploitées sur des systèmes obsolètes.
• Délai d'inactivité : fermez les sessions inactives avec ClientAliveInterval 300.

Questions fréquentes

Comment me connecter si je perds ma clé privée ?

Si vous avez désactivé la connexion par mot de passe et perdu votre seule clé, vous ne pouvez plus entrer par SSH. Ajoutez donc plusieurs clés à authorized_keys, ou gardez l'accès console/récupération de votre hébergeur (la console web du panneau VPS) prêt. Vous pourrez y générer une nouvelle clé et l'ajouter.

Changer de port suffit-il à lui seul comme sécurité ?

Non. Changer de port ne fait que réduire le bruit du scan automatisé ; un attaquant ciblé scannera facilement votre port. La vraie sécurité vient de la désactivation des mots de passe et de l'usage de clés, plus une défense en couches comme fail2ban.

Pourquoi fail2ban me bannit-il parfois ?

Cela arrive généralement à cause de tentatives répétées avec une mauvaise passphrase, un mauvais nom d'utilisateur ou une ancienne clé. Vérifiez avec fail2ban-client status sshd et libérez-vous avec unbanip ; vous pouvez aussi ajouter votre IP statique à la ligne ignoreip.

Vous voulez rendre votre serveur inviolable ? Durcissons ensemble le SSH et le pare-feu de votre serveur de jeu, VPS ou hébergement web. Contactez-moi et sécurisons votre infrastructure de bout en bout.