Comment durcir la configuration du serveur SSH
Dernière mise à jour:
Le fichier sshd_config est toute la posture de sécurité de votre serveur SSH dans un seul fichier texte — et sur la plupart des systèmes, il est livré dans un état optimisé pour la compatibilité, pas pour la sécurité. La connexion par mot de passe est activée par défaut, root peut se connecter tant qu’une clé est utilisée, les sessions inactives n’expirent jamais et les algorithmes proposés par votre serveur sont ceux qu’a décidés la version d’OpenSSH installée il y a des années. Le durcir ne consiste pas à copier une liste de contrôle de 2021 : les algorithmes sont retirés, les valeurs par défaut changent et une configuration exemplaire il y a cinq ans peut être faible aujourd’hui. Cet article explique ce que chaque changement fait réellement, pourquoi l’ordre de vos décisions compte et comment tester une nouvelle configuration sans vous retrouver dehors. Vous pouvez auditer votre propre fichier ligne par ligne dans l’auditeur de configuration du serveur SSH, qui le compare à une base de référence datée du 2026-11-13, entièrement dans votre navigateur.
Les valeurs par défaut sont un point de départ, pas une posture de sécurité
OpenSSH est livré avec des valeurs par défaut choisies pour qu’une installation neuve fonctionne pour le plus grand nombre — et c’est exactement pourquoi elles ne constituent pas une posture de sécurité. Les valeurs actuelles, telles que documentées dans la page de manuel de sshd_config, comprennent PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 secondes et ClientAliveInterval 0, ce qui signifie que les sessions inactives ne sont jamais terminées. Aucune n’est un bug : chacune est un choix délibéré de compatibilité, et chacune est un constat dans un audit de durcissement.
La conséquence pratique est qu’un serveur que personne n’a jamais durci reste accessible par devinette de mot de passe, accepte toujours les connexions root avec une clé volée et laisse les sessions abandonnées ouvertes indéfiniment. Les valeurs par défaut changent aussi avec le temps — ce qu’apporte OpenSSH 10.6 n’est pas ce qu’apportait OpenSSH 7 — donc « je n’ai jamais rien changé » n’est pas une affirmation neutre. Cela signifie que votre posture de sécurité est celle qu’a décidée la version que vous avez installée, et la seule façon de le savoir est de lire le fichier. C’est le premier travail d’un audit : rendre visibles les valeurs par défaut invisibles, car une directive absente du fichier reste en vigueur.
Désactiver les mots de passe vaut mieux que changer de port, à chaque fois
Le changement le plus efficace dans sshd_config est PasswordAuthentication no combiné à PubkeyAuthentication yes : à partir de ce moment, aucun mot de passe — deviné, divulgué ou hameçonné — ne peut ouvrir une session, car le démon n’accepte plus ce type de preuve. L’authentification par clé transforme l’attaque de « deviner un secret choisi par un humain » en « voler un fichier de clé privée qui ne traverse jamais le réseau », et c’est pourquoi toutes les bases de durcissement, y compris celle de Mozilla, commencent ici. Si vous ne retenez qu’une chose de cet article, que ce soit celle-ci : générez une paire de clés (voir la suite de clés SSH et l’article compagnon les clés SSH expliquées), installez la clé publique, vérifiez que vous pouvez vous connecter avec, et seulement ensuite désactivez les mots de passe.
Changer le port de 22 vers un port obscur, en revanche, n’est pas du durcissement — c’est de l’obscurité. Cela réduit le bruit dans vos journaux, car la plupart des scanners d’Internet ne frappent qu’au port 22, mais cela n’arrête aucun attaquant qui prend la peine de scanner : un balayage de ports trouve le démon en quelques secondes, et le démon derrière est exactement aussi solide que sa configuration. L’auditeur traite donc un port différent de 22 comme une simple information, jamais comme une amélioration notée. Il y a un piège à connaître avant de basculer : sur les systèmes qui utilisent PAM, PasswordAuthentication no seul ne suffit pas — l’authentification par clavier interactif peut encore laisser PAM accepter un mot de passe, donc la pile PAM de /etc/pam.d/sshd doit aussi refuser les mots de passe. Les directives de Mozilla le disent explicitement, et c’est la moitié du changement la plus souvent oubliée.
Connexion root : ce que prohibit-password autorise vraiment
PermitRootLogin a quatre valeurs, et la différence entre elles est la différence entre une piste d’audit et aucune. La valeur par défaut, prohibit-password, permet à root de se connecter — simplement pas avec un mot de passe. Une clé root volée entre quand même sans obstacle, et une fois la session root, rien dans les journaux ne distingue un administrateur d’un autre. Le profil Modern de Mozilla le fixe à No, et c’est la réponse durcie : root ne devrait jamais être un compte de connexion. Connectez-vous comme un utilisateur nommé et utilisez sudo ; chaque action privilégiée est alors attribuable à une personne.
Les valeurs intermédiaires existent pour une raison, et elles méritent d’être connues plutôt que craintes. forced-commands-only permet la connexion root uniquement lorsque la clé présentée est restreinte à une seule commande dans authorized_keys — le modèle qu’utilisent les scripts de sauvegarde et de supervision — et c’est un choix légitime et délibéré pour l’automatisation. Ce qui n’est pas légitime, c’est yes, qui autorise la connexion root par mot de passe et constitue une erreur dans tout audit. La règle pratique : si un humain se connecte en root, la configuration est fausse ; si c’est un script, restreignez la clé à une commande et dites-le dans un commentaire, car la prochaine personne qui lira le fichier le « corrigera » sinon.
Le retrait des algorithmes est une cible mouvante
Les algorithmes de votre configuration ont une date d’expiration, plus courte que vous ne le pensez. OpenSSH 10.0, publié le 2025-04-09, a supprimé entièrement la prise en charge de DSA (ssh-dss), retiré le Diffie-Hellman à champ fini de l’échange de clés par défaut du serveur et fait de mlkem768x25519-sha256 — un hybride post-quantique — l’accord de clés par défaut. Une configuration copiée d’un billet de blog de 2021 peut encore lister diffie-hellman-group1-sha1, 3des-cbc, arcfour ou hmac-md5, qui sont tous des erreurs dans un audit moderne et dont certains ne sont même plus pris en charge par le démon installé. La configuration n’a pas changé ; le monde, si.
C’est pourquoi une base de durcissement doit porter une date, et pourquoi revérifier fait partie du travail, pas une réflexion après coup. Le profil Modern de Mozilla — échange de clés curve25519, chiffrements chacha20-poly1305 et AES-GCM, MAC SHA-2 chiffrer-puis-authentifier — est la référence, mais il est antérieur aux échanges de clés post-quantiques qu’OpenSSH 10.0 a rendus par défaut, donc un audit de 2026 accepte aussi mlkem768x25519-sha256 et sntrup761x25519-sha512 à côté. L’habitude qui vous tient à jour coûte peu : une ou deux fois par an, exécutez ssh -Q kex, ssh -Q cipher et ssh -Q mac sur le serveur pour voir ce que la version installée propose réellement, comparez avec les directives actuelles de Mozilla et repassez l’auditeur sur le même fichier. Un score propre de 2021 est un document historique, pas un document actuel.
Blocs Match et Include : les deux façons dont un audit propre ment
Un fichier de configuration n’est pas une liste plate de réglages — c’est un programme avec des branches conditionnelles, et deux fonctionnalités peuvent faire qu’un fichier qui se lit comme durci se comporte comme s’il ne l’était pas. La première est le bloc Match : les directives à l’intérieur de Match User, Match Group ou Match Address ne s’appliquent que lorsque les critères sont remplis, et la page de manuel est explicite : si un mot-clé apparaît dans plusieurs blocs Match satisfaits, seule la première occurrence est appliquée. Un PasswordAuthentication no global suivi d’un bloc Match qui réactive discrètement les mots de passe pour un groupe est une configuration réelle, et c’est exactement le genre de chose qu’une lecture ligne par ligne manque. Les constats venant de l’intérieur d’un bloc Match sont conditionnels, jamais globaux, et tout audit honnête les délimite ainsi.
La seconde est Include. Les distributions modernes découpent sshd_config en plusieurs fichiers — /etc/ssh/sshd_config.d/*.conf est le modèle habituel — et une directive Include intègre ces fichiers, par ordre lexical, à l’endroit où elle apparaît. Comme la première valeur obtenue l’emporte, une directive fixée dans un fichier inclus éclipse la même directive plus loin dans le fichier principal : la ligne que vous lisez n’est pas la ligne qui gouverne. Un auditeur qui tourne dans le navigateur ne peut pas suivre les Include — les fichiers ne sont pas sur votre machine — donc il les signale comme « non suivis » et liste le chemin. Quand vous auditez, auditez tout le répertoire, pas un seul fichier, et souvenez-vous qu’une directive dupliquée n’est pas une faute de frappe à ignorer : la première l’emporte et la seconde est du texte mort qui confondra la prochaine personne qui modifiera le fichier.
Le déploiement sûr : tester avant de fermer la porte
Chaque changement de sshd_config comporte le même risque : une faute de frappe peut empêcher le démon de redémarrer, et un réglage correct mais erroné peut vous refuser l’accès. Le déploiement qui évite les deux est court et non négociable. D’abord, vérifiez la syntaxe avec sshd -t avant de toucher le service en cours d’exécution — il analyse le fichier et signale les erreurs sans rien démarrer. Redémarrez ou rechargez ensuite le démon, et testez seulement après. Ne modifiez jamais la configuration et ne fermez jamais votre seule session dans le même geste.
Le test lui-même est la discipline : gardez votre session actuelle ouverte, ouvrez une seconde session et reconnectez-vous avec les nouvelles règles en vigueur. Si la seconde connexion fonctionne, le changement est sûr et la première session peut être fermée ; sinon, la session ouverte est votre porte de sortie, et vous pouvez revenir sur le fichier et recharger. C’est aussi pourquoi les changements doivent être faits un par un sur un serveur que vous ne pouvez pas atteindre physiquement — un fichier de clés cassé et une méthode par mot de passe désactivée dans la même modification ne laissent aucune issue. L’auditeur peut produire une version durcie de votre fichier comme point de départ, mais c’est un brouillon à revoir, bloc Match par bloc Match, et à tester avec sshd -t — jamais un fichier à déposer sans relecture.