Hardening SSH : la trilogie de 2017 relue en 2026

En octobre 2017, un article de hardening SSH passe sur ma timeline. Analyse généraliste, contre-mesures naïves. Je réponds en trois commentaires : la désactivation du root, le changement de port, l’authentification par clés. Neuf ans plus tard, ces trois commentaires me servent d’inventaire : ce qui tenait, ce qui a changé et ce qui n’était pas dans le cadre mais l’aurait mérité.

D’abord un point de principe, celui qui m’avait fait tiquer : comparer OpenSSH à une simple interface d’administration est réducteur. SSH, ce sont les bastions d’accès au SI, les VPN SSH, l’industrialisation agentless (Ansible, Puppet Bolt) qui passent par dessus. C’est la colonne vertébrale d’administration de la plupart des parcs Unix. Le durcir mal, c’est durcir tout le SI mal.

1. Le compte root : fermer ce qu’on peut, cadrer ce qui reste

Désactiver l’accès root direct en SSH réduit une partie de la surface d’attaque. Mais certains impératifs métier nécessitent de tels accès et je le déplore. Quand l’accès root doit exister, OpenSSH offre des mécanismes de limitation :

• command= dans authorized_keys pour ne permettre qu’une commande donnée, avec un wrapper bien écrit qui limite les lolbins comme on le ferait dans un sudoers.
• from= pour restreindre la source, avec une bonne segmentation côté ~/.ssh/config et ~/.ssh/config.d/.
• La limitation d’allocation de TTY, de X11 forwarding et le reste de la panoplie.

authorized_keys est la section du man que les gens ne lisent jamais et pourtant c’est la base de nombre de bastions faits maison dans les règles de l’art. AuthorizedKeysCommand et AuthorizedKeysCommandUser permettent en plus de déporter la distribution des clés, ce qui rend la gestion centralisée possible sans centrale fragile.

Et l’anecdote qui justifie mon ton de l’époque : j’ai souvent vu des serveurs avec le compte root “désactivé”, des comptes d’accès du type admin:123456 et le sudoers en NOPASSWD:ALL. Le check box de conformité est coché, le serveur est une porte ouverte. Lors d’une véritable attaque, ces contre-mesures ne font que gagner du temps et encore.

2. Le port : le débat qui n’en est pas un

Changement du port standard : en dehors des scans automatisés et du bypass de firewalling, cela ne fait que ralentir une véritable attaque. Ma position de 2017 : laisser le daemon sur le 22 et utiliser du portknocking ou du SPA. J’ai même écrit une variante de portknocking basée uniquement sur les flags TCP de ports généralement non filtrés, variant selon une variable temporelle.

[edit: 2026] Dix ans plus tard, je maintiens le diagnostic (changer de port ne sert à rien contre un attaquant sérieux) mais le traitement a changé : WireGuard ignore silencieusement tout paquet non authentifié et produit le même effet d’invisibilité, sans couche opérationnelle en plus. L’argument complet est dans La sécurité par l’obscurité n’est pas de la sécurité . Le portknocking, quand j’en garde un, c’est un mécanisme d’urgence avant de devoir me taper la console KVMoIP/IPMI du fournisseur. Un plan B, pas une architecture.

Pour le serveur qui ne doit vraiment pas être exposé : le daemon n’écoute que sur la boucle locale et on passe par un tunnel. La question du port devient alors celle du point d’entrée et donc celle du bastion.

3. Les clés : ed25519 et tout le reste

Le commentaire de 2017 tenait en une phrase : oui, systématiquement, avec la meilleure crypto du moment (ed25519) et des restrictions de ciphers disponibles, côté serveur comme côté client. Le détail de la config vit dans hardening SSH et SSH moderne . Le reste :

• Utilisateur humain : passphrase robuste obligatoire.
• Machine à machine : limitation de commande obligatoire (command=), sinon la clé est un mot de passe qui se copie.
• Agent forwarding et X11 forwarding : à désactiver par défaut, activer au cas par cas.

Rien de tout cela n’a vieilli. Ce qui a vieilli, c’est le côté client et c’est la suite.

4. Ce que 2017 ne voyait pas : le client et la chaîne d’approvisionnement [edit: 2026]

La moitié de la discussion SSH en 2017 parlait serveur. En 2026, le maillon faible est souvent côté client.

Premier cas : le poste Windows. Le client OpenSSH natif existe depuis des années et un bon vieux ~/.ssh/config fait le travail : alias, ProxyJump, Match host. Les sessions vivent alors dans un fichier texte qu’on relit, qu’on templatise et qu’on distribue par dépôt Git ou par GPO, plutôt que dans la base de registre. On évite le .ppk et ses conversions par puttygen et surtout on sort d’une chaîne de distribution qui a déjà servi : PuTTY trojanisé par UNC4034 en 2022, campagnes de malvertising et de SEO poisoning sur les requêtes “download putty”. Le client SSH est un logiciel qu’on installe : l’installer depuis la bonne source fait partie du hardening.

L’installation native a des trous, soyons précis : pas de ControlMaster ni ControlPersist côté Windows donc pas de multiplexage, pas de console série (PuTTY garde l’avantage pour reprendre le port COM), pas de ssh-copy-id d’office, X11 forwarding suppose un serveur X tiers. Ce sont des trous connus et cadrés, pas des raisons de revenir à une chaîne d’appro trojanisable.

5. Le bastion : un point d’entrée unique, pas un magicien [edit: 2026]

Le bastion vous donne un point d’entrée unique vers vos machines, qu’il s’agisse de vos prestataires ou de vos employés. Ce que j’ai appris à formuler précisément en 2025, après une question “est-ce que le bastion peut empêcher un presta de faire X” :

• Non. Si les presta possèdent les privilèges d’administration nécessaires sur la machine et même sans, via escalade de privilèges, alors ils peuvent faire ce qu’ils veulent. Ce n’est pas le taf du bastion de faire cela.
• Ce qui vous en protège est ailleurs : une politique de moindre privilège systématique et l’isolation réseau. Si seul le bastion possède les ouvertures de flux vers l’administration distante des machines d’un VLAN et que les machines du VLAN ne les ont pas entre elles, un rebond d’une machine à l’autre est en théorie impossible. Seulement du bastion vers les machines auxquelles l’utilisateur est autorisé.

Le mouvement latéral se prévient par l’architecture, pas par le point d’entrée. Le bastion concentre les logs et les accès, il ne remplace ni l’un ni l’autre.

6. La compromission que personne ne met dans les guides

En 2017 aussi : limiter une clé à une IP, tcpwrappers, denyhosts, hosts.allow/hosts.deny, filtrer avec iptables ou en amont, mais cela pourrait nuire aux utilisateurs en mobilité. Il est souvent nécessaire de faire des compromis entre sécurité et confort d’utilisation et d’administration.

Un guide qui ne mentionne pas ce compromis vend une configuration qui sera démontée par les utilisateurs. Le durcissement SSH qui survit trois mois en prod est celui qui intègre la mobilité dès la première version.

7. Le mur final : la menace physique [edit: 2026]

Un dernier point, que j’avais formulé en 2025 à propos de l’authentification biométrique : suffira de te prendre l’empreinte ou de te couper les doigts. Dans le cas d’une intrusion physique où vos serveurs et équipements sont la cible, il faut penser à cela, comme aux contraintes psychologiques et physiques d’obtention d’un secret. Une simple hache ou un coup de bélier et c’est fini.

Le hardening SSH protège contre un attaquant à distance sur le port 22. Il ne protège pas contre l’accès physique et le dire fait partie de la discipline. C’est pour cela que les mécanismes de measured boot, le chiffrement disque avec secret détachable et la planification de réponse à incident existent et qu’ils ne figurent pas dans les mêmes guides.

Récapitulatif [edit: 2026]

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles ssh et ssh-users .