Durcissement SSH 2026 : Algorithmes, Certificats et Bastion Hosts

Chaque fois qu'on ouvre shodan.io en filtrant sur port:22, on trouve encore des centaines de milliers de serveurs acceptant ssh-rsa avec SHA-1, l'authentification par mot de passe exposee en plein internet et des MACs comme hmac-sha1. En 2026, ce n'est plus une vieille config oubliee : c'est une dette technique qui paie ses interets sous forme d'incidents. Le durcissement SSH n'est plus une checklist de six lignes dans sshd_config, c'est devenu un petit sous-systeme avec CA interne, bastion auditable, materiel de cle a courte duree et telemetrie centralisee. Ce guide parcourt toute la pile telle que l'equipe Basilisk la monte en laboratoire avant la production, avec une configuration concrete, des commandes reelles et les modes de defaillance qu'on rencontre sans cesse.

Pourquoi SSH reste la porte preferee de l'attaquant

SSH est le protocole d'administration distante de quasiment tout Linux et de la plupart des equipements reseau, ce qui en fait la credential de plus grande valeur du parc. Les attaquants l'adorent parce qu'une seule cle ou un seul mot de passe valide donne un shell interactif avec les privileges du compte cible, sans chaine d'exploit. Les trois causes racines recurrentes sont : cles reutilisees ou jamais tournees qui survivent a l'employe qui les a creees ; authentification par mot de passe brute-forcee depuis des botnets ; et downgrade vers des algorithmes faibles qui laisse un attaquant reseau manipuler le handshake. Traitez SSH comme un systeme d'identite, pas comme un utilitaire. Chaque decision de conception ci-dessous reduit l'une de ces trois classes, et l'ordre compte : reparez l'authentification avant la telemetrie, car journaliser une breche que vous ne pouvez pas empecher vous dit seulement quand vous avez perdu.

Base de sshd_config non negociable

Commencez par le daemon serveur. Dans un /etc/ssh/sshd_config moderne, forcez PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin no, UsePAM yes et PermitEmptyPasswords no. Ajoutez MaxAuthTries 3, LoginGraceTime 20 et ClientAliveInterval 300 pour que les sessions semi-ouvertes meurent. Limitez la portee avec AllowGroups ssh-users plutot que d'autoriser chaque compte local. Validez le fichier avant de recharger avec sshd -t, et ne modifiez jamais le port en production sans une seconde session ouverte, car une faute de frappe dans un bloc Match peut vous verrouiller dehors. Ces directives sont le plancher : aucune ne coute rien et toutes retirent une primitive d'attaque.

Algorithmes modernes et echange de cles post-quantique

Limitez KexAlgorithms a sntrup761x25519-sha512@openssh.com,curve25519-sha256, Ciphers a chacha20-poly1305@openssh.com,aes256-gcm@openssh.com et MACs a hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com. L'hybride sntrup761 apporte une resistance post-quantique depuis OpenSSH 9.0, et en 2026 il n'y a plus de raison de ne pas l'activer : il protege le trafic capture aujourd'hui contre le dechiffrement quantique de demain, le probleme harvest-now-decrypt-later. Lancez ssh-audit avant et apres. L'ecart entre un C+ et un A se joue surtout en coupant diffie-hellman-group14-sha1, les chiffrements CBC et les MACs tronques. Preferez les variantes etm (encrypt-then-MAC) car elles authentifient le texte chiffre, pas le texte clair. Considerez le passage de ssh-audit comme un prerequis, pas comme un livrable.

Remplacer les cles eparpillees par une CA SSH interne

Le vrai saut de maturite arrive quand vous mettez a la retraite les fichiers authorized_keys et emettez des certificats. Generez une paire de cles CA (ssh-keygen -t ed25519 -f ssh_user_ca) dont la moitie privee ne vit que dans un HSM ou un signeur hors ligne, puis signez des certificats utilisateur avec un TTL court de 4 a 12 heures : ssh-keygen -s ssh_user_ca -I alice@corp -n alice -V +8h user_key.pub. Sur chaque serveur vous ne distribuez que la cle publique de la CA via TrustedUserCAKeys /etc/ssh/ca.pub. L'utilisateur s'authentifie avec un certificat emis par step-ca, HashiCorp Vault SSH ou Teleport, lie au SSO de l'entreprise. Revoquer l'acces d'un ex-salarie cesse d'etre une chasse aux cles sur 400 hotes et devient simplement la non-reemission du certificat. En pentest interne, ce seul changement coupe la moitie des chemins de mouvement lateral bases sur des cles orphelines, car la cle volee ne vaut plus rien des que son certificat a expire.

Le bastion comme proxy d'identite, pas comme jump box

Un bastion durci n'est pas un Linux quelconque avec SSH ouvert. Voyez-le comme un proxy d'identite : il recoit la connexion utilisateur, valide le certificat contre la CA, enregistre toute la session (entree et sortie) et ouvre un second SSH vers la cible via ProxyJump. Teleport, HashiCorp Boundary et la combinaison step-ca + auditd + tlog couvrent ce cas. Sur une configuration typique pour un client fintech, le bastion vivait dans un VPC isole dont le Security Group n'autorisait que le port 22 depuis le VPN interne, et les serveurs refusaient tout SSH ne venant pas du CIDR du bastion. Cela ramene la surface d'attaque de centaines d'IPs joignables depuis internet a un seul point de passage surveille ou chaque frappe est journalisee et chaque session est imputable a une identite humaine.

Durcissement cote client et cles adossees au materiel

N'oubliez pas le client. Forcez ~/.ssh/config avec HashKnownHosts yes, VerifyHostKeyDNS yes quand c'est applicable, et generez une cle adossee au materiel avec ssh-keygen -t ed25519-sk pour que la moitie privee ne quitte jamais une YubiKey et que chaque authentification exige un contact physique. Lancez ssh-agent avec confirmation (ssh-add -c) pour qu'une station compromise ne reutilise pas le socket de l'agent en silence. Desactivez les options inutiles : AllowAgentForwarding no et AllowTcpForwarding no cote serveur sauf si un flux documente l'exige, car l'agent forwarding vers un hote non fiable permet a cet hote de detourner votre agent tant que le socket est vivant.

CI/CD et cles de service sans secrets a longue duree

Les identites machine sont souvent l'endroit ou l'acces humain durci refuit. Interdisez les cles statiques en CI. Emettez plutot des certificats courts via OIDC GitHub Actions ou GitLab contre votre Vault, pour qu'un pipeline recoive un certificat valide quelques minutes, limite a l'hote exact qu'il doit atteindre. Cela elimine toute la classe d'incidents ou une cle fuitee dans un log reste valide pendant des annees. Pour les cibles de deploiement, utilisez des blocs Match qui lient un certificat de service a une seule commande avec ForceCommand et PermitOpen, transformant un shell general en une action etroite et auditable qui ne peut pas etre detournee en acces interactif.

Journalisation centralisee et detections qui declenchent vraiment

La journalisation ferme la boucle. Activez LogLevel VERBOSE sur sshd pour enregistrer les fingerprints de cle, envoyez /var/log/auth.log via journald-remote ou Fluent Bit vers Elastic ou Loki, puis ecrivez des regles Sigma pour les motifs qui comptent : echecs repetes suivis d'un succes depuis la meme source, login avec un certificat expirant dans moins d'une heure, un principal de certificat qui ne correspond pas a l'utilisateur SSO, ou des commandes suspectes capturees par session recording. Lors d'une simulation red team, il nous a fallu 11 minutes pour etre detectes en reutilisant une cle volee precisement parce que le principal du certificat ne correspondait pas a l'identite SSO et que la regle de correlation a alerte. Sans cette correlation, on aurait tenu des jours. SSH est l'une des sources de telemetrie les plus riches et les plus sous-exploitees que vous possediez.

Pieges frequents qui annulent votre durcissement en silence

Les erreurs recurrentes : laisser PermitRootLogin prohibit-password et croire que c'est fini alors qu'une cle root partagee existe encore ; durcir le daemon mais laisser ~/.ssh/authorized_keys inscriptible par l'utilisateur, de sorte que toute execution de code reajoute une cle ; oublier que les blocs Match sont evalues de haut en bas et qu'un match large et precoce masque un match strict ulterieur ; et faire tourner les host keys sans mettre a jour la distribution de known_hosts, ce qui apprend aux utilisateurs a ignorer les avertissements de host key. Un autre tueur silencieux est un MaxStartups sans limite qui laisse un flot de connexions epuiser le daemon. Auditez cela explicitement ; aucun n'apparait comme une erreur, ils laissent seulement la porte entrouverte.

Checklist de durcissement

Avant de declarer un hote durci, verifiez : note A a ssh-audit ; auth par mot de passe et clavier-interactif desactivee ; login root coupe ; uniquement KEX, chiffrement et MAC modernes ; certificats emis par la CA avec TTL sous 12 heures ; TrustedUserCAKeys configure et aucun authorized_keys egare ; entree uniquement par le bastion imposee au niveau reseau ; session recording actif ; logs VERBOSE envoyes et au moins trois regles Sigma vivantes ; cles client adossees au materiel ; aucune cle statique en CI ; et un runbook d'urgence capable de revoquer et reemettre toute la flotte en moins d'une heure. Si une ligne reste non cochee, l'hote n'est pas termine.

FAQ : Le SSH par certificat est-il excessif pour une petite equipe ?

Non. Meme a cinq ingenieurs, une CA interne elimine le pire risque operationnel, les cles orphelines, et se monte en une apres-midi avec step-ca. Le point d'equilibre n'est pas la taille de la flotte, c'est le moment ou une deuxieme personne a besoin d'acceder a un deuxieme hote, car c'est la que la gestion manuelle des authorized_keys commence a deriver. Commencez avec un TTL de 8 heures lie a votre fournisseur d'identite et grandissez ensuite.

FAQ : Activer sntrup761 casse-t-il les vieux clients ?

Les clients sur un OpenSSH anterieur a 9.0 ne negocient pas le KEX hybride et retombent simplement sur curve25519-sha256, d'ou son maintien dans la liste. La reponse pratique est de mettre a jour les clients : toute station encore sur un OpenSSH anterieur a 9.0 est en retard de correctifs pour d'autres raisons. Gardez le KEX post-quantique en tete de l'ordre de preference pour que les clients modernes l'obtiennent automatiquement.

Take-away pratique : montez un labo avec trois VMs (CA, bastion, cible) en step-ca, fixez un TTL de 8 heures, forcez les algorithmes modernes, lancez ssh-audit jusqu'a atteindre A, puis essayez de vous connecter avec une vieille cle. Si ca passe, votre config n'est pas encore durcie. Refaites l'exercice chaque trimestre, faites tourner la cle de la CA chaque annee, et gardez le runbook d'urgence teste. SSH reste la porte d'entree preferee des attaquants en 2026 precisement parce qu'on le traite en infrastructure invisible. Arretez de le traiter ainsi.