Durcir un serveur SSH sans perdre l'accès

Objectif

Réduire l'exposition d'un serveur SSH aux mots de passe devinés, aux agents volés et aux erreurs de configuration, tout en gardant un moyen garanti de revenir en arrière pendant le changement.

Prérequis

Un accès root ou sudo sur l'hôte, une paire de clés sur la machine de l'administrateur (ssh-keygen -t ed25519 avec une phrase de passe), la clé publique déjà présente dans ~/.ssh/authorized_keys du compte qui sera utilisé, et une console hors bande (console du fournisseur cloud, IPMI) dont le bon fonctionnement est connu.

Étapes

1. Ouvrir une seconde session SSH et la laisser ouverte pendant toute la procédure ; une session déjà active survit à un redémarrage de sshd et permet d'annuler une erreur.
2. Vérifier que la connexion par clé fonctionne dans une session neuve (ssh -o PasswordAuthentication=no user@host).
3. Modifier /etc/ssh/sshd_config ou un fichier dans sshd_config.d/ : PasswordAuthentication no, KbdInteractiveAuthentication no (sa valeur par défaut est yes, selon sshd_config(5)), PermitRootLogin no (ou prohibit-password là où des clés root sont incontournables), PubkeyAuthentication yes.
4. Limiter qui peut se connecter avec AllowUsers ou AllowGroups ; pour les comptes d'automatisation, ajouter un bloc Match User avec ForceCommand, AllowTcpForwarding no et PermitTTY no.
5. Resserrer la fenêtre de pré-authentification : MaxAuthTries 3 (valeur par défaut 6), LoginGraceTime 30 (valeur par défaut 120 secondes), et PerSourcePenalties si la version du serveur le prend en charge.
6. Désactiver ce qui n'est pas utilisé : X11Forwarding no, AllowAgentForwarding no là où personne n'en a besoin (le manuel note que cela n'aide que si les comptes n'ont pas non plus d'accès shell).
7. Exécuter sshd -t pour valider le fichier, puis redémarrer ou recharger le service et se connecter depuis une troisième session avant de fermer la seconde.
8. Côté client, utiliser ProxyJump pour atteindre des hôtes situés derrière un bastion plutôt que ForwardAgent ; ssh(1) avertit que quiconque peut contourner les permissions de fichiers sur l'hôte distant peut utiliser un agent transféré. Si le transfert est incontournable, charger les clés avec ssh-add -c afin que chaque utilisation demande une confirmation.
9. Consigner le changement et l'empreinte de la clé d'hôte du serveur dans le runbook.

Résultat attendu

La devinette de mots de passe ne donne rien, root ne peut plus être ciblé directement, seuls les comptes listés existent comme cibles, et l'administrateur peut toujours se connecter avec la clé testée. journalctl -u ssh (ou sshd, selon la distribution) montre les tentatives échouées coupées après trois essais.

Limites et base de vérification

Les paquets des distributions livrent leurs propres valeurs par défaut et fichiers d'inclusion ; sshd_config(5) indique que la première valeur obtenue pour un mot-clé est celle utilisée, et que les motifs Include sont développés dans l'ordre lexical ; vérifier donc la configuration effective avec sshd -T. Cette liste de contrôle ne couvre que les réglages de sshd ; les limites au niveau réseau (pare-feu, port knocking, bannissement de type fail2ban) et l'authentification à deux facteurs relèvent de décisions distinctes. Les noms d'options et leurs valeurs par défaut proviennent des pages de manuel citées en référence ; aucune mesure n'est revendiquée.