Fermez les mots de passe SSH et les réseaux de zombies se lassent

L'affirmation

Tout port SSH public reçoit des milliers d'essais de mots de passe par jour dans les heures qui suivent sa mise en ligne. Les réponses habituelles — changer le port, installer fail2ban, limiter la cadence — traitent le bruit. Désactiver entièrement l'authentification par mot de passe traite la vulnérabilité : une attaque par essais contre un serveur à clés seules n'a aucun coup à jouer. C'est une ligne de configuration, et l'essentiel du rituel entourant le durcissement de SSH devient facultatif dès qu'elle est posée.

La configuration

Confirmez d'abord que votre propre clé fonctionne — depuis un second terminal, pendant que le premier reste connecté :

ssh-keygen -t ed25519 -a 64
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hote

Puis, dans /etc/ssh/sshd_config :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deploy admin

sshd -t && systemctl reload sshd

sshd -t valide le fichier avant le rechargement — une erreur de syntaxe dans ce fichier précis vous enferme dehors avec précision. Gardez la première session ouverte jusqu'à ce qu'une connexion neuve réussisse. Vérifiez aussi /etc/ssh/sshd_config.d/ pour les fragments fournis par la distribution : sur les Ubuntu récents, un fichier de cloud-init peut y réactiver les mots de passe dans votre dos, et les fragments l'emportent.

Pourquoi les clés closent le débat

Une clé ed25519 est un secret de 256 bits. L'essai de mots de passe fonctionne parce que l'espace des mots de passe humains est petit et structuré ; il n'existe aucune campagne équivalente contre un espace de 2²⁵⁵, et les attaquants le savent — observez vos journaux après le changement : les tentatives s'effondrent en un filet de balayeurs qui constatent le port ouvert et passent leur chemin. La catégorie d'incident où le mot de passe réutilisé d'un pigiste, exposé dans une fuite sans rapport, ouvre votre serveur n'est pas rendue plus difficile. Elle est rendue impossible, faute de mot de passe à réutiliser.

Protégez la clé privée par une phrase secrète, car le modèle de menace se déplace du serveur vers le portable qui détient la clé. Un agent met la phrase en cache par session : le coût est de la taper une fois le matin.

Ce dont vous n'avez plus besoin, et ce qui reste

Changer de port relève du théâtre après cela — les balayeurs trouvent le 2222 dans la même passe que le 22, et les ports non standard embrouillent surtout vos propres outils. fail2ban passe de contrôle de sécurité à hygiène de journaux ; gardez-le si le bruit vous agace, mais rien n'en dépend. Ce qui compte encore :

• Les correctifs de sshd lui-même. L'authentification par clés ne protège pas d'une vulnérabilité du démon. Les mises à jour automatiques couvrent cela.
• L'inventaire des clés. Le contrôle passe des mots de passe aux fichiers authorized_keys ; vérifiez-les :

  for u in $(cut -d: -f1 /etc/passwd); do
    f="/home/$u/.ssh/authorized_keys"
    [ -f "$f" ] && echo "== $u" && wc -l < "$f"
  done

  Chaque clé devrait correspondre à une personne ou à un système nommé. Un fichier de neuf clés pour une liste de quatre employés, c'est votre processus de départ qui rapporte lui-même son échec.
• La double authentification là où un humain se connecte interactivement. Une clé adossée au matériel — résidente sur un jeton de sécurité — donne une authentification par possession sans codes à usage unique.

Réduisez l'auditoire à zéro quand c'est possible

La version plus forte de cet article, c'est que le port 22 ne devrait pas être joignable d'internet du tout. Une interface WireGuard ou le tunnel à identité de votre fournisseur infonuagique place SSH sur un réseau privé, et la surface d'attaque publique de l'administration à distance se réduit à un port UDP qui ne répond pas aux paquets non authentifiés. Pour un petit parc, c'est un après-midi de travail. Le SSH sans mot de passe demeure la bonne pratique à l'intérieur du tunnel — la défense en profondeur, au sens ennuyeux de deux contrôles indépendants.

Le plan de secours à préparer d'abord

L'objection honnête : « et si je perds la clé ». Répondez-y avant de basculer, pas après : inscrivez deux clés par administrateur, conservées séparément — une sur la machine de tous les jours, une sur un jeton dans un tiroir — et confirmez que la console hors bande de votre fournisseur fonctionne, car cette console est la voie de secours qui ne passe pas du tout par SSH. Testez-la une fois. Faites ensuite le changement, surveillez le journal d'authentification une semaine, et savourez sa lecture pour la première fois : le bruit parti, le journal ne contient enfin que des entrées qui veulent dire quelque chose.