Sécuriser SSH sur un VPS : clés, root désactivé et Fail2ban

Dès qu'un serveur reçoit une adresse IP publique, des robots tentent de s'y connecter en SSH avec des listes de mots de passe courants. Ce n'est pas une menace théorique : lancez journalctl -u ssh | grep -c Failed sur un VPS en ligne depuis quelques jours, le compteur se chiffre souvent en milliers. Ce guide rend ces tentatives inutiles.

1. Pourquoi c'est la première chose à faire

Un mot de passe peut être deviné, réutilisé ou divulgué. Une clé SSH ED25519, elle, ne peut pas être devinée en pratique. En combinant trois mesures, on élimine l'essentiel du risque :

• Authentification par clé uniquement : les mots de passe ne sont plus acceptés du tout.
• Connexion root interdite : un attaquant doit deviner un nom d'utilisateur en plus.
• Fail2ban : les adresses qui insistent sont bannies automatiquement.

2. Créer et installer une clé SSH

Sur votre ordinateur :

ssh-keygen -t ed25519 -C "alex@portable"

Choisissez une phrase de passe : si votre ordinateur est volé, la clé reste inutilisable. Copiez ensuite la clé publique vers le compte utilisateur du serveur (créé dans les premiers pas) :

ssh-copy-id alex@IP_SERVEUR

Sous Windows, où ssh-copy-id n'existe pas, la commande équivalente est donnée dans les premiers pas sur votre VPS. Vérifiez que ssh alex@IP_SERVEUR fonctionne sans demander de mot de passe avant d'aller plus loin.

3. Durcir la configuration

Plutôt que de modifier le fichier principal /etc/ssh/sshd_config, créez un fichier dédié dans le dossier de configuration : il n'est pas écrasé par les mises à jour et regroupe vos réglages au même endroit.

cat > /etc/ssh/sshd_config.d/00-durcissement.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers alex
EOF

AllowUsers n'autorise que les comptes listés : séparez-les par des espaces si vous en avez plusieurs. MaxAuthTries coupe la connexion après trois essais.

4. Le piège de cloud-init

Le nom du fichier commence par 00-, et ce n'est pas un hasard. Pour chaque paramètre, OpenSSH retient la première valeur lue, et les fichiers du dossier sont lus par ordre alphabétique. Or beaucoup d'images Ubuntu contiennent un fichier 50-cloud-init.conf avec PasswordAuthentication yes. Nommé 99-..., votre fichier serait lu après et silencieusement ignoré : les mots de passe resteraient acceptés.

ls /etc/ssh/sshd_config.d/

Pour savoir quelle valeur s'applique réellement, interrogez directement le serveur SSH :

sshd -T | grep -E "permitrootlogin|passwordauthentication|kbdinteractive|allowusers"

5. Changer le port (optionnel)

Changer le port 22 ne protège pas contre un attaquant qui vous vise, qui trouvera le nouveau port en quelques secondes. En revanche, cela fait disparaître l'essentiel des tentatives automatiques des journaux. Si vous le faites, ajoutez la ligne Port 2222 au fichier précédent, et ouvrez le port dans le pare-feu d'abord :

ufw allow 2222/tcp

6. Appliquer sans se bloquer

Vérifiez la syntaxe, puis rechargez SSH. Ne fermez pas votre session en cours.

sshd -t && systemctl reload ssh

Ouvrez un second terminal et testez :

ssh alex@IP_SERVEUR                # doit fonctionner
ssh root@IP_SERVEUR                # doit être refusé
ssh -o PubkeyAuthentication=no alex@IP_SERVEUR   # doit être refusé

Si la première commande échoue, corrigez depuis la session restée ouverte. Si vous avez changé de port, ajoutez -p 2222 à chaque commande ; une fois la connexion validée sur le nouveau port, retirez l'ancienne règle du pare-feu avec ufw delete allow OpenSSH.

7. Installer Fail2ban

Fail2ban lit les journaux et bannit, via le pare-feu, les adresses qui accumulent les échecs. Même avec les mots de passe désactivés, il allège la charge et les journaux.

apt install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
banaction = ufw

[sshd]
enabled  = true
backend  = systemd
port     = ssh
maxretry = 3
bantime  = 24h
EOF
systemctl enable --now fail2ban
systemctl restart fail2ban

Si vous avez changé de port, remplacez port = ssh par port = 2222. backend = systemd est nécessaire sur Debian 12, qui n'écrit plus de fichier /var/log/auth.log par défaut ; il est placé dans la section [sshd] et non dans [DEFAULT], pour ne pas perturber les jails qui liront plus tard des fichiers, comme celles de Nginx. Pour protéger aussi Nginx, la messagerie ou WordPress, voir Fail2ban avancé.

8. Vérifier

fail2ban-client status sshd
journalctl -u ssh --since "1 hour ago" | tail

La première commande affiche le nombre d'adresses bannies. Pour aller plus loin, ajoutez un second facteur à la connexion : voir activer la double authentification sur SSH. Et complétez avec un pare-feu en liste blanche : configurer UFW.

Questions fréquentes