Sécuriser SSH sur un VPS

Pourquoi SSH est la première chose à durcir

SSH est le moyen par lequel vous contrôlez votre serveur, ce qui en fait la serrure que tout attaquant essaie en premier. Dès qu'un VPS est en ligne, des scanners commencent à deviner des noms d'utilisateur et des mots de passe sur le port 22. Vous pouvez le constater dans vos journaux en quelques minutes. Durcir SSH consiste à supprimer ce qu'ils peuvent deviner : désactivez complètement la connexion par mot de passe, désactivez la connexion root, et n'autorisez que les clés cryptographiques. Une fois cela fait, les tentatives incessantes ne peuvent tout simplement pas aboutir, car il n'y a aucun mot de passe à trouver.

Ceci suppose que SSH fonctionne déjà. Si vous pouvez vous connecter, vous pouvez le durcir. Effectuez les étapes dans l'ordre et gardez votre session actuelle ouverte jusqu'à ce qu'une nouvelle fonctionne, afin qu'une erreur ne vous verrouille jamais dehors.

Étape 1 : vérifier d'abord que l'authentification par clé fonctionne

L'authentification par clé remplace un mot de passe par une paire de clés : une clé privée qui reste sur votre ordinateur et une clé publique que vous placez sur le serveur. Le serveur prouve que vous détenez la clé privée sans qu'elle quitte jamais votre machine. Avant de désactiver les mots de passe, confirmez que les clés fonctionnent, sinon vous vous verrouillerez dehors.

Sur votre propre ordinateur, créez une clé si vous n'en avez pas :

ssh-keygen -t ed25519

Copiez la moitié publique sur le serveur :

ssh-copy-id user@your-server

Puis ouvrez une nouvelle session SSH. Si elle vous laisse entrer sans demander de mot de passe, votre clé fonctionne et vous pouvez désactiver les mots de passe en toute sécurité. Si les clés sont nouvelles pour vous, ou si vous utilisez plusieurs ordinateurs, les bases de la gestion des clés SSH explique le modèle complet : une clé par appareil, les permissions qu'exige sshd, et comment révoquer une clé quand un ordinateur portable disparaît.

Étape 2 : durcir sshd avec un fichier drop-in

Ne modifiez pas /etc/ssh/sshd_config directement. Ubuntu 24.04 lit les fichiers drop-in depuis /etc/ssh/sshd_config.d/, et un petit fichier à cet endroit est plus propre, survit aux mises à niveau de paquets, et est facile à supprimer si quelque chose tourne mal. Le nom a son importance : sshd conserve la première valeur qu'il lit pour chaque paramètre, et les images cloud d'Ubuntu fournissent 50-cloud-init.conf avec PasswordAuthentication yes dans ce répertoire. Nommez votre fichier 00- pour qu'il soit trié avant celui-là et l'emporte ; un fichier 99- perd silencieusement. Créez-en un :

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Mettez-y ceci :

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Chaque ligne ferme une porte. PasswordAuthentication no est la plus importante : sans mots de passe, une attaque par force brute n'a rien à forcer. KbdInteractiveAuthentication no ferme une seconde voie de type mot de passe. PermitRootLogin no signifie qu'un attaquant doit connaître votre nom d'utilisateur et détenir votre clé, au lieu de simplement viser le seul compte, root, qui existe sur chaque machine.

Étape 3 : tester la configuration, puis la recharger

Vérifiez la configuration à la recherche d'erreurs avant de l'appliquer, pour qu'une faute de frappe ne puisse pas casser le service :

sudo sshd -t

Si rien ne s'affiche, la configuration est valide. Rechargez SSH :

sudo systemctl reload ssh

Ensuite, vérifiez les paramètres que sshd utilise réellement, afin de repérer un drop-in qui aurait perdu face à un autre fichier :

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Les deux doivent indiquer no. Maintenant, sans fermer votre session actuelle, ouvrez-en une toute nouvelle depuis un autre terminal. Si elle vous connecte avec votre clé, vous avez terminé. Si quelque chose ne va pas, votre première session est toujours ouverte pour corriger. Ce chevauchement est le filet de sécurité, alors ne le sautez jamais.

Étape 4 : le port non standard optionnel

Déplacer SSH du port 22 vers quelque chose comme 2222 ne le rend pas plus sûr au sens réel, car un attaquant déterminé scanne tous les ports. Ce que cela fait, c'est réduire le bruit dans les journaux, puisque la plupart des scanners automatisés n'essaient que le 22. Si vous le souhaitez, ajoutez Port 2222 à votre fichier drop-in, autorisez d'abord le nouveau port dans le pare-feu, puis exécutez sudo systemctl daemon-reload && sudo systemctl restart ssh.socket et connectez-vous avec ssh -p 2222. Sur Ubuntu 24.04, ssh.socket possède le port d'écoute, donc un simple reload ssh laisse sshd sur le 22 ; c'est le redémarrage du socket qui prend en compte le nouveau port. Considérez-le comme du rangement, pas comme une protection.

Étape 5 : superposer les défenses supplémentaires

Les clés SSH durcies sont la fondation, et deux couches supplémentaires s'ajoutent par-dessus.

Fail2ban surveille vos journaux et bannit les adresses qui échouent de façon répétée, ce qui réduit le bruit des scanners et les évince tôt. Il se marie naturellement avec l'authentification par clé uniquement : voir Fail2ban sur Ubuntu pour stopper les attaques SSH.

Plus fort encore : garder SSH totalement hors de l'internet public. Si vous placez SSH derrière un VPN WireGuard et que vous filtrez le port 22 vers le tunnel, personne en dehors du VPN ne peut même l'atteindre, et deviner par force brute devient impossible plutôt que simplement difficile. Tout ceci suppose un pare-feu en refus par défaut en dessous, c'est-à-dire UFW configuré sur le VPS.

SSH n'est qu'une ligne d'une liste de contrôle plus large : les 10 premières minutes sur un nouveau VPS met les étapes dans l'ordre, et les mises à jour de sécurité automatiques sur Ubuntu maintiennent la machine à jour ensuite.

FAQ

Comment désactiver la connexion par mot de passe pour SSH sur Ubuntu 24.04 ?

Créez un fichier drop-in dans /etc/ssh/sshd_config.d/00-hardening.conf (le préfixe 00 le fait trier avant 50-cloud-init.conf, dont le PasswordAuthentication yes l'emporterait sinon, car sshd conserve la première valeur qu'il lit) contenant PasswordAuthentication no et KbdInteractiveAuthentication no, exécutez sudo sshd -t pour le vérifier, puis sudo systemctl reload ssh. Confirmez que la connexion par clé fonctionne dans une nouvelle session avant de vous y fier. Modifier un drop-in plutôt que sshd_config survit aux mises à niveau de paquets et se défait facilement.

Faut-il désactiver la connexion root via SSH ?

Oui. Définissez PermitRootLogin no pour que personne ne puisse se connecter directement en tant que root. Connectez-vous avec votre utilisateur normal et utilisez sudo pour les tâches d'administration. Root existe sur chaque machine Linux, donc le laisser accessible offre à un attaquant un nom d'utilisateur connu à viser. Le désactiver signifie qu'il doit connaître le nom de votre compte et détenir votre clé.

Changer le port SSH rend-il mon serveur plus sûr ?

Pas de façon significative. Quitter le port 22 vous cache des scanners paresseux qui ne sondent que le 22, ce qui réduit le bruit dans les journaux, mais un vrai attaquant scanne tous les ports et le trouve quand même. C'est l'authentification par clé uniquement qui stoppe réellement les intrusions. Si vous changez le port, ouvrez d'abord le nouveau dans le pare-feu, puis exécutez sudo systemctl daemon-reload && sudo systemctl restart ssh.socket ; sur Ubuntu 24.04, le socket possède l'écoute, et un simple reload laisse sshd sur le port 22.

Ai-je besoin de Fail2ban si j'utilise des clés SSH ?

C'est optionnel mais toujours utile. Avec l'authentification par clé uniquement, deviner les mots de passe ne peut pas aboutir, donc Fail2ban n'est pas ce qui tient les attaquants à l'écart. Il limite le rythme des échecs répétés d'une même adresse, ce qui réduit le bruit des scanners dans vos journaux et évince tôt les récidivistes ; une attaque lente et distribuée reste de toute façon sous son seuil de bannissement. Exécutez-le par-dessus l'authentification par clé, et idéalement gardez SSH derrière un VPN.

Comment récupérer si je me verrouille hors de SSH ?

Utilisez la console web de votre hébergeur, qui atteint le serveur via une connexion série ou VNC qui ne passe pas par SSH. De là, vous pouvez vous connecter, corriger le fichier drop-in sshd, et recharger le service. C'est exactement pourquoi vous testez une nouvelle configuration SSH dans un second terminal avant de fermer votre première session, et pourquoi l'authentification par clé devrait déjà fonctionner avant de désactiver les mots de passe.