sshd garde la première valeur lue, et ton durcissement arrive trop tard

Ligne 57 de /etc/ssh/sshd_config, sur un serveur, le 16 septembre 2026 : PasswordAuthentication no. Je lance sshd -T | grep passwordauthentication, il me répond yes. Le serveur contredit son propre fichier de configuration.

Presque partout, la dernière valeur écrite l'emporte. OpenSSH fait l'inverse : pour un mot-clé donné, il retient la première qu'il rencontre et ignore les suivantes. Et sur Debian 13, la ligne Include /etc/ssh/sshd_config.d/*.conf se trouve en ligne 12, tout en haut. Les drop-ins sont donc lus avant le corps du fichier, et ils gagnent contre lui, quelle que soit la ligne où tu écris ta directive.

Sur cette machine, l'hébergeur avait posé un 50-cloud-init.conf à la création, avec PasswordAuthentication yes dedans. La ligne 57 ne servait à rien. L'accès par mot de passe a été fermé le jour même.

Entre deux drop-ins, c'est l'ordre alphabétique, et là encore le premier lu gagne. Pour écraser 50-cloud-init.conf, ton fichier doit donc être trié avant lui : 20-hardening.conf, pas 60-hardening.conf. Un fichier nommé en 60 est lu, accepté, et n'a aucun effet.

Je m'étais planté dans ce sens-là. La consigne que j'avais rédigée demandait un nom trié après le 50. La vérification sur la machine a dit le contraire, et la règle était écrite en toutes lettres dans l'en-tête d'un 10-limits.conf déjà présent sur mon propre parc.

Lire les fichiers ne tranche rien. sshd -T rend la configuration effective, celle que le démon applique, tous les Include résolus. Après chaque changement :

sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'

Et tu ne fermes pas ta session avant d'en avoir ouvert une seconde.

retour aux notes