SSH est le service le plus attaqué de tout serveur public, et c'est aussi le plus facile à fermer correctement. Presque tout le risque vient d'une seule chose : les mots de passe. Supprimez-les et les tentatives continuent sans plus avoir d'importance.
La configuration
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers sara deploy
sudo sshd -t && sudo systemctl reload ssh
Avant de recharger : ayez une clé qui fonctionne, et un second terminal déjà connecté. Mettez PasswordAuthentication no sans clé installée et vous vous êtes enfermé dehors de votre propre serveur — la console de l'hébergeur devient alors le seul retour possible.
Ligne par ligne
- PermitRootLogin no — travaillez sous un utilisateur nommé, avec sudo. Voir Utilisateurs, sudo, et ne jamais travailler en root.
- PasswordAuthentication no — de loin la ligne la plus précieuse de la liste.
- KbdInteractiveAuthentication no — ferme la seconde voie de mot de passe qu'on oublie, et qui maintient discrètement les mots de passe en état de marche.
- AllowUsers — une liste explicite. Un nouveau compte système créé par un paquet ne peut pas se connecter.
Restreignez d'où il répond
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw deny 22/tcp
Si une adresse fixe de bureau est impossible, Fail2ban est la solution de repli — voir Ce que Fail2ban arrête. Déplacer le port est cosmétique ; voir Changer le port SSH.
Vérifiez ce que vous obtenez au final
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers'
sshd -T affiche la configuration effective, y compris ce qui est défini dans un fichier Include plus bas. C'est la seule lecture qui tienne compte d'une distribution déposant un fichier dans sshd_config.d et vous passant devant.