Comment sécuriser SSH sur un VPS

Pourquoi SSH est la première chose à sécuriser

SSH vous permet de contrôler votre serveur. C’est donc le verrou que les attaquants essaient en premier. Dès qu’un VPS est en ligne, des scanners commencent à tester des noms d’utilisateur et des mots de passe sur le port 22. Vous pouvez le constater dans vos journaux en quelques minutes. Sécuriser SSH consiste à supprimer ce qu’ils peuvent deviner : désactivez complètement l’authentification par mot de passe, désactivez la connexion de root et n’autorisez que les clés cryptographiques. Une fois ces mesures appliquées, les tentatives répétées ne peuvent tout simplement plus aboutir, car aucun mot de passe n’est disponible à trouver.

Cela suppose que SSH fonctionne déjà. Si vous pouvez vous connecter, vous pouvez le sécuriser. Suivez les étapes dans l’ordre et gardez votre session actuelle ouverte jusqu’à ce qu’une nouvelle session fonctionne. Vous éviterez ainsi qu’une erreur vous empêche de vous connecter.

Étape 1 : Vérifiez d’abord que l’authentification par clé fonctionne

L’authentification par clé remplace le 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 vérifie que vous détenez la clé privée sans qu’elle quitte votre machine. Avant de désactiver les mots de passe, vérifiez que les clés fonctionnent. Sinon, vous risquez de ne plus pouvoir vous connecter.

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

ssh-keygen -t ed25519

Copiez la partie publique sur le serveur :

ssh-copy-id user@your-server

Ouvrez ensuite une nouvelle session SSH. Si vous pouvez vous connecter sans saisir de mot de passe, votre clé fonctionne et vous pouvez désactiver les mots de passe sans risque. Si la connexion s’arrête avec Permission denied (publickey), cette erreur peut correspondre à cinq problèmes différents, et la sortie de ssh -v vous indique lequel avant que vous ne modifiiez quoi que ce soit d’autre. Si les clés vous sont peu familières ou si vous utilisez plusieurs ordinateurs, les bases de la gestion des clés SSH expliquent le modèle complet : une clé par appareil, les permissions exigées par sshd et la procédure de révocation d’une clé lorsqu’un ordinateur portable est perdu.

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

Ne modifiez pas directement /etc/ssh/sshd_config. Ubuntu 24.04 lit les fichiers drop-in dans /etc/ssh/sshd_config.d/. Un petit fichier à cet emplacement est plus propre, résiste aux mises à niveau des paquets et se supprime facilement en cas de problème. Le nom est important : sshd conserve la première valeur lue pour chaque paramètre, et les images cloud Ubuntu fournissent 50-cloud-init.conf avec PasswordAuthentication yes dans ce répertoire. Nommez votre fichier 00- afin qu’il soit classé avant celui-ci et soit prioritaire ; un fichier 99- est ignoré sans message. Créez-le :

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

Placez-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 voie d’accès. PasswordAuthentication no est le paramètre principal : avec les mots de passe désactivés, une attaque par force brute n’a plus rien à tester. KbdInteractiveAuthentication no désactive une deuxième méthode d’authentification reposant sur un mot de passe. PermitRootLogin no signifie qu’un attaquant doit connaître votre nom d’utilisateur et posséder votre clé, au lieu de pouvoir simplement cibler le seul compte, root, présent sur chaque machine.

Étape 3 : Tester la configuration, puis la recharger

Vérifiez la configuration pour détecter les erreurs avant de l’appliquer. Une faute de frappe ne pourra ainsi pas interrompre le service :

sudo sshd -t

Si la commande n’affiche rien, la configuration est valide. Rechargez SSH :

sudo systemctl reload ssh

Vérifiez ensuite les paramètres effectivement utilisés par sshd. Vous détecterez ainsi un drop-in qui aurait été supplanté par un autre fichier :

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

Les deux commandes doivent afficher no. Sans fermer votre session actuelle, ouvrez maintenant une toute nouvelle session depuis un autre terminal. Si la connexion s’effectue avec votre clé, vous avez terminé. En cas de problème, votre première session est toujours ouverte pour effectuer les corrections. Ce chevauchement constitue votre filet de sécurité : ne le sautez jamais.

Étape 4 : Le port non standard facultatif

Déplacer SSH du port 22 vers un port comme 2222 ne le rend pas réellement plus sécurisé, car un attaquant déterminé analyse tous les ports. Cette modification réduit toutefois le bruit dans les journaux, car la plupart des scanners automatisés essaient uniquement le port 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 gère le port en écoute. Un simple reload ssh laisse donc sshd sur le port 22 ; c’est le redémarrage du socket qui applique le nouveau port. Considérez cette modification comme une mesure de rangement, pas comme une protection.

Étape 5 : Ajouter des défenses supplémentaires

Des clés SSH renforcées constituent la base. Deux couches supplémentaires viennent s’y ajouter.

Fail2ban surveille vos journaux et bannit les adresses qui échouent à répétition. Cela réduit le bruit des scanners et les écarte rapidement. Il s’associe naturellement à l’authentification par clé uniquement : voir Configurer Fail2ban sur Ubuntu pour bloquer les attaques SSH.

Une protection encore plus forte consiste à retirer complètement SSH de l’Internet public. Si vous placez SSH derrière un VPN WireGuard et limitez le port 22 au tunnel, personne en dehors du VPN ne peut même l’atteindre. Les tentatives par force brute deviennent alors impossibles, et pas seulement difficiles. Tout cela suppose la présence d’un pare-feu avec une politique de refus par défaut. Voir Configurer UFW sur le VPS.

SSH ne représente qu’un élément d’une liste de contrôle plus large : les 10 premières minutes sur un nouveau VPS présente les étapes dans l’ordre, et les mises à jour de sécurité automatiques sur Ubuntu maintiennent ensuite le serveur à jour. Verrouiller la porte ne protège pas les services qui se trouvent derrière. Si ce même VPS exécute un coffre-fort de mots de passe, renforcer Vaultwarden couvre les deux éléments que l’authentification par clé ne protège jamais : son jeton d’administration et son fichier de sauvegarde.

FAQ

Comment désactiver l’authentification 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 passer avant 50-cloud-init.conf, dont la valeur PasswordAuthentication yes l’emporterait sinon, car sshd conserve la première valeur qu’il lit. Ajoutez-y PasswordAuthentication no et KbdInteractiveAuthentication no, exécutez sudo sshd -t pour vérifier la configuration, puis sudo systemctl reload ssh. Vérifiez que la connexion par clé fonctionne dans une nouvelle session avant de vous y fier. Modifier un fichier drop-in plutôt que sshd_config permet de conserver la configuration lors des mises à niveau des paquets et facilite son annulation.

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

Oui. Définissez PermitRootLogin no afin 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. Le compte root existe sur tous les systèmes Linux. Le laisser accessible fournit donc à un attaquant un nom d’utilisateur connu à cibler. Le désactiver l’oblige à connaître le nom de votre compte et à posséder votre clé.

Modifier le port SSH rend-il mon serveur plus sécurisé ?

Pas de manière significative. Utiliser un port différent du port 22 vous dissimule aux scanners peu sophistiqués qui testent uniquement le port 22, ce qui réduit le bruit dans les journaux. Un véritable attaquant analyse tous les ports et le trouvera malgré tout. C’est l’authentification par clé uniquement qui bloque réellement les compromissions. Si vous modifiez le port, ouvrez d’abord le nouveau port dans le firewall, puis exécutez sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. Sur Ubuntu 24.04, le socket gère l’écoute, et un simple reload laisse sshd sur le port 22.

Fail2ban est-il nécessaire si j’utilise des clés SSH ?

Il est facultatif, mais reste utile. Avec une authentification par clé uniquement, une attaque par devinettes de mots de passe ne peut pas aboutir. Fail2ban n’est donc pas ce qui empêche les attaquants d’entrer. Il limite le débit des échecs répétés provenant d’une même adresse. Cela réduit le bruit généré par les scanners dans vos journaux et bloque rapidement les récidivistes. Une attaque lente et distribuée reste toutefois sous son seuil de bannissement. Utilisez-le en complément de l’authentification par clé et, idéalement, gardez SSH derrière un VPN.

Comment récupérer l’accès si je me verrouille hors de SSH ?

Utilisez la console web de votre fournisseur. Elle accède au serveur via une connexion série ou VNC qui ne passe pas par SSH. Vous pouvez alors vous connecter, corriger le fichier drop-in sshd et recharger le service. C’est précisément pour cette raison qu’il faut tester une nouvelle configuration SSH dans un deuxième terminal avant de fermer la première session. L’authentification par clé doit également déjà fonctionner avant de désactiver les mots de passe.