Un serveur qui accepte un mot de passe root sur le port 22 se fait essayer en continu. Au bout d’un moment, l’hébergeur voit une source d’attaques et verrouille la machine. La parade n’est pas un mot de passe plus long. C’est de ne plus accepter de mot de passe du tout.
La clé avant la coupure
On génère une paire de clés sur le poste qui doit administrer le serveur. La clé privée reste sur ce poste. La clé publique est ajoutée dans ~/.ssh/authorized_keys de l’utilisateur qui se connectera, pas de root si on peut l’éviter.
On ouvre une seconde session avec cette clé, sans fermer la première. Tant que la seconde n’affiche pas un shell, on ne touche pas à la configuration. Couper le mot de passe avant ce test, c’est se retrouver dehors.
Ce que sshd doit refuser
Dans /etc/ssh/sshd_config :
PubkeyAuthentication yesPasswordAuthentication noKbdInteractiveAuthentication noPermitRootLogin no
On vérifie la syntaxe avec sshd -t, puis on recharge le service. On ne redémarre pas la machine pour « voir ». La session déjà ouverte reste valide. Une troisième tentative, depuis un autre terminal, doit échouer si elle n’a pas la clé.
Le pare-feu autour
Le port 22 n’a pas besoin d’être ouvert au monde entier si vous vous connectez toujours depuis les mêmes adresses. Quand ce n’est pas possible, la clé reste obligatoire : un scan de mots de passe n’a plus rien à essayer. CrowdSec, décrit dans l’article sur le moteur et les bouncers, retire en plus les adresses qui insistent. Il ne remplace pas l’absence de mot de passe.
Ce qu’il ne faut pas laisser
- Une clé privée dans le dépôt Git, dans une image Docker ou dans un ticket.
- La même clé copiée sur tous les postes de l’équipe sans phrase de passe.
- Un accès root direct « juste pour Ansible ». Ansible se connecte avec l’utilisateur nommé, puis élève les droits.
