Protocole SSH, clés d’hôte, authentification et durcissement

SSH (Secure Shell) est le canal par lequel passe l’administration de presque tous les serveurs Unix, d’une bonne partie des équipements réseau et d’une quantité respectable de transferts de fichiers. Sa cryptographie est rarement le maillon faible. Les incidents viennent plutôt de la confiance accordée à la clé d’hôte, des clés privées qui traînent et des redirections qui transforment un accès d’administration en tunnel vers tout le réseau.

→ Lire l’explication complète de la marmotte

Architecture SSH-2 : transport, authentification utilisateur et canaux

SSH-2 est défini par quatre RFC (Request for Comments) publiées en 2006 : la RFC 4251 pour l’architecture, la RFC 4253 pour la couche transport, la RFC 4252 pour l’authentification de l’utilisateur et la RFC 4254 pour la couche connexion. SSH-1 est cassé et ne doit plus exister nulle part. Si un équipement ne parle que SSH-1, il faut le traiter comme un service en clair.

La couche transport est déployée au-dessus de TCP (Transmission Control Protocol). Elle commence par un échange de chaînes de version (SSH-2.0-...), puis chaque côté envoie un message SSH_MSG_KEXINIT qui liste ses algorithmes par ordre de préférence. L’échange de clés éphémère vient ensuite. Il s’agit de Curve25519, ou d’un hybride post-quantique dans les versions récentes d’OpenSSH : sntrup761x25519-sha512 est le défaut depuis OpenSSH 9.0, puis mlkem768x25519-sha256 (ML-KEM, Module-Lattice-based Key Encapsulation Mechanism) l’est devenu avec OpenSSH 10.0. Le serveur signe alors le hash d’échange H avec sa clé d’hôte. Ce point est le seul ancrage d’authenticité de toute la session : si le client ne vérifie pas cette clé, l’échange de clés reste parfaitement confidentiel avec n’importe qui, y compris avec l’attaquant installé au milieu. Le premier H devient l’identifiant de session. Le chiffrement et l’intégrité reposent sur un AEAD (Authenticated Encryption with Associated Data) comme chacha20-poly1305@openssh.com ou aes256-gcm@openssh.com, ou à défaut sur un chiffrement CTR associé à un MAC (Message Authentication Code). Un renouvellement des clés (rekeying) a lieu périodiquement.

La couche d’authentification (service ssh-userauth) ne commence qu’une fois le canal chiffré. En authentification par clé, la signature de l’utilisateur couvre l’identifiant de session. Une signature capturée ne peut donc pas être rejouée sur une autre session.

La couche connexion multiplexe des canaux dans un seul tunnel. Chaque canal possède sa propre fenêtre de contrôle de flux. Les principaux types sont session (shell, commande, sous-système SFTP), direct-tcpip (redirection locale), forwarded-tcpip (redirection distante), x11 et auth-agent@openssh.com. Retenir ce point : un shell interactif et un tunnel vers une base de données sont, pour le protocole, deux canaux de même rang.

Le schéma suivant montre l’ordre des échanges. La vérification de la clé d’hôte précède toute authentification de l’utilisateur, et les canaux n’existent qu’après le succès de celle-ci.

Confiance dans la clé d’hôte : TOFU, known_hosts, SSHFP et certificats

Par défaut, OpenSSH applique le modèle TOFU (Trust On First Use). À la première connexion, il affiche une empreinte SHA-256 et demande de l’accepter. La clé est ensuite enregistrée dans ~/.ssh/known_hosts et comparée à chaque connexion. Le modèle protège bien contre un attaquant qui arrive après le premier contact. Il ne protège en rien contre celui qui est déjà là au premier contact. Vingt ans de métier apprennent d’ailleurs que le nombre de personnes qui comparent réellement l’empreinte affichée tend vers le nombre de personnes qui lisent les conditions générales.

Les directives client qui comptent :

StrictHostKeyChecking accepte les valeurs yes, accept-new, ask (valeur par défaut) et no. La valeur accept-new est le bon compromis pour l’automatisation : elle enregistre une clé inconnue, mais refuse une clé différente. La valeur no dans un script de CI ou d’Ansible revient à désactiver l’authentification du serveur, sans autre forme de procès.
HashKnownHosts yes remplace les noms d’hôte par des hachages. Le fichier ne sert alors plus de carte du parc à un attaquant qui a pris pied sur un poste.
UpdateHostKeys permet au serveur d’annoncer ses autres clés d’hôte, ce qui facilite une rotation.

Quand l’empreinte change, le message REMOTE HOST IDENTIFICATION HAS CHANGED est soit une réinstallation, soit une interception. Rien dans le protocole ne permet de distinguer les deux. La règle tient en un arbre de décision :

La vérification hors bande suppose que l’empreinte ait été relevée quelque part au moment de la création de l’hôte, par exemple avec ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Sans référentiel, « vérifier l’empreinte » se réduit à un rituel.

Les enregistrements SSHFP (SSH Fingerprint), définis par la RFC 4255 et étendus par les RFC 6594 et 7479, publient l’empreinte de la clé d’hôte dans le DNS (Domain Name System). La commande ssh-keygen -r nom-hôte les génère. Côté client, VerifyHostKeyDNS yes les consulte. La protection ne vaut que si la réponse est validée par DNSSEC (DNS Security Extensions) et que le chemin entre le client et son résolveur validant est de confiance, puisque le client se fie au bit AD (Authenticated Data) renvoyé par le résolveur. Un SSHFP servi sans DNSSEC remplace un TOFU par une confiance aveugle dans le premier résolveur venu.

Les certificats d’hôte sont la réponse qui tient à l’échelle. Une CA (Certificate Authority) SSH signe la clé d’hôte (directive serveur HostCertificate), et le client fait confiance à la CA via une ligne @cert-authority dans known_hosts. Les réinstallations ne déclenchent plus d’alerte, et une alerte redevient un signal. Le détail (émission, principals, révocation) est traité dans Certificats SSH et risques de l’agent forwarding. Il n’est pas repris ici.

Un dernier piège concerne les images système clonées. Elles embarquent toutes la même clé d’hôte si elle a été générée dans l’image : un seul serveur compromis permet alors d’usurper tous les autres. Une clé générée au tout premier démarrage sur une machine virtuelle pauvre en entropie hérite de la même fragilité. Il faut supprimer les clés de l’image et les régénérer au premier démarrage (ssh-keygen -A crée les types manquants), après initialisation du générateur aléatoire, comme le détaille Produire de l’aléa utilisable en cryptographie.

Authentification de l’utilisateur : mot de passe, Ed25519, FIDO et certificats

Le mot de passe (méthodes password et keyboard-interactive, souvent relayées par PAM, Pluggable Authentication Modules) se devine, se réutilise et part chez le serveur à chaque connexion. Le canal est chiffré, mais un serveur usurpé ou compromis reçoit le secret en clair. Sur un serveur exposé, il n’a plus sa place.

La clé publique est la base. Ed25519 est le choix par défaut : clés courtes, signature rapide, pas de dépendance à la qualité de l’aléa au moment de signer. RSA reste acceptable pour les vieux équipements, à condition d’utiliser des signatures rsa-sha2-256 ou rsa-sha2-512. Les signatures ssh-rsa en SHA-1 sont désactivées par défaut depuis OpenSSH 8.8, et DSA a disparu des versions récentes. Le point faible n’est pas l’algorithme, mais la clé privée elle-même : un fichier copiable, souvent sans phrase de passe, parfois versionné dans un dépôt « privé ». Côté serveur, le fichier authorized_keys accepte des restrictions par clé : from="198.51.100.0/24", command="..." et restrict, qui coupe redirections, agent et allocation de terminal d’un seul mot. Une clé de sauvegarde automatisée devrait systématiquement porter restrict et une command= forcée.

Les clés matérielles FIDO (Fast IDentity Online), types ed25519-sk et ecdsa-sk disponibles depuis OpenSSH 8.2, laissent la clé privée dans le jeton. Le fichier sur disque n’est qu’une poignée inutilisable sans le jeton branché. La présence physique (toucher le jeton) est exigée par défaut. L’option -O verify-required à la génération ajoute un PIN (Personal Identification Number), et le serveur peut l’exiger via PubkeyAuthOptions verify-required. Le prix à payer : un jeton perdu signifie un accès perdu, il faut donc un second jeton enregistré. Il faut aussi que le serveur soit assez récent pour connaître ces types.

Les certificats utilisateur ajoutent une durée de validité et des principals sans toucher aux authorized_keys du parc. Là encore, renvoi à la page dédiée.

La position à tenir est la suivante. Au-delà de quelques serveurs, la combinaison qui tient est une clé FIDO pour les humains, plus des certificats de courte durée émis par une CA pour distribuer cette confiance. Les clés logicielles sans phrase de passe sont réservées aux comptes de service, restreintes par restrict, from= et command=. Le compromis est explicite : on gagne une clé qui ne fuit plus et des accès qui expirent seuls ; on paie une CA à protéger comme une PKI et une gestion des jetons. Sur un parc de cinq machines, authorized_keys et des clés FIDO suffisent. La question qui tranche : combien d’accès faut-il retirer le jour où quelqu’un part ?

Redirections de ports, ProxyJump, transfert d’agent et SFTP

Les fonctions qui rendent SSH indispensable sont exactement celles qui en font un outil de contournement.

Redirection locale (-L 8080:interne:80) : un port local est relayé, via le serveur SSH, vers une destination que le serveur atteint. On traverse ainsi la segmentation avec les droits réseau du serveur.
Redirection distante (-R 2222:localhost:22) : un port s’ouvre sur le serveur et revient vers le réseau du client. Un poste interne qui sort en SSH vers une machine externe offre ainsi à cette machine un accès entrant permanent, sans qu’aucune règle entrante du pare-feu n’ait été touchée. C’est la porte dérobée de base, et elle tient en une option.
Redirection dynamique (-D 1080) : un proxy SOCKS (Socket Secure) local fait sortir n’importe quel flux TCP par le serveur.
Tunnel de niveau 3 (-w, directive serveur PermitTunnel) : un VPN complet, à peu de frais.

Un pare-feu qui autorise le SSH sortant autorise donc, de fait, tout le reste. Les contre-mesures sont réseau et non protocolaires. Il faut filtrer le SSH sortant vers une liste de destinations connues. Il faut aussi détecter SSH sur des ports inattendus : la bannière SSH-2.0- circule en clair et trahit le protocole même sur le port 443. Enfin, il faut imposer un bastion unique, conformément aux principes de filtrage et segmentation.

Côté serveur, AllowTcpForwarding no ne vaut que pour les comptes sans shell. La page de manuel d’OpenSSH le dit elle-même : un utilisateur doté d’un shell peut installer son propre relais. Les directives de restriction (AllowTcpForwarding, PermitOpen, PermitListen, GatewayPorts, PermitTunnel, DisableForwarding) servent surtout sur les comptes à usage restreint et sur le bastion.

ProxyJump contre transfert d’agent. Avec ProxyJump (-J bastion), le bastion ne relaie qu’un canal direct-tcpip. La session SSH vers la cible est négociée de bout en bout depuis le poste, et le bastion ne voit ni clé ni contenu. Avec ForwardAgent, le bastion expose une socket vers l’agent du poste : tant que la session est ouverte, quiconque est root sur le bastion peut s’authentifier n’importe où avec les clés de l’utilisateur. La règle est sans appel : ProxyJump partout, transfert d’agent désactivé par défaut, comme le détaillent la page sur les certificats SSH et celle sur VPN, tunnels et bastions. Sur le bastion, ProxyJump exige que les redirections TCP restent permises. Il faut donc les borner avec PermitOpen vers les seules cibles autorisées.

La topologie ci-dessous montre ce qui circule : le bastion relaie un flux TCP dont il ne peut lire que l’enveloppe externe.

SFTP (SSH File Transfer Protocol) est un sous-système qui tourne dans un canal session. Pour un compte de dépôt de fichiers, on combine ForceCommand internal-sftp, ChrootDirectory et DisableForwarding yes dans un bloc Match. Le répertoire de chroot doit appartenir à root et n’être inscriptible par personne d’autre, sinon sshd refuse la connexion. Un compte SFTP sans DisableForwarding reste un compte de tunnel qui dépose aussi des fichiers.

Algorithmes hérités, Terrapin, xz-utils et regreSSHion

Algorithmes hérités. Échange de clés diffie-hellman-group1-sha1, chiffrements CBC, MAC en hmac-md5 ou hmac-sha1, clés ssh-dss : OpenSSH les a retirés de ses listes par défaut, mais des équipements réseau anciens les exigent encore. Avec ssh -Q kex (ou cipher, mac, key), on liste ce que le client sait faire. Avec sshd -T, on obtient la configuration effective du serveur. Réactiver un algorithme hérité pour un seul vieux commutateur se fait dans un bloc Host côté client, jamais globalement.

Terrapin (CVE-2023-48795, décembre 2023) est une attaque par troncature de préfixe. Un attaquant en position d’interception manipule les numéros de séquence pendant l’échange de clés, que ces numéros ne protègent pas, puis supprime des messages au tout début du canal chiffré sans que l’intégrité ne le détecte. Sont touchés chacha20-poly1305@openssh.com et les modes CBC combinés aux MAC Encrypt-then-MAC (-etm) ; AES-GCM ne l’est pas. Sur OpenSSH, l’effet pratique est la suppression du message EXT_INFO, donc la dégradation de certaines négociations. D’autres implémentations ont subi des conséquences plus graves. La correction, l’extension « strict kex » d’OpenSSH 9.6, remet les compteurs à zéro au changement de clés et interdit les messages parasites pendant l’échange initial. Elle ne protège que si les deux extrémités la prennent en charge. Un client à jour face à un équipement réseau figé reste exposé, d’où l’intérêt d’inventorier les versions des serveurs SSH et pas seulement des postes.

La porte dérobée xz-utils (CVE-2024-3094, découverte fin mars 2024) a été insérée dans les versions 5.6.0 et 5.6.1 de xz-utils par un mainteneur qui avait gagné la confiance du projet sur la durée. OpenSSH ne dépend pas de liblzma. Mais plusieurs distributions liaient sshd à libsystemd pour la notification de service, et libsystemd charge liblzma. Le code malveillant détournait alors la vérification de clé RSA de sshd pour exécuter des commandes portées par une clé signée par l’attaquant. Elle a été repérée pour l’essentiel avant d’atteindre les branches stables des grandes distributions. La leçon est architecturale : la surface d’attaque de sshd inclut toute sa chaîne de bibliothèques chargées, y compris celles ajoutées par les correctifs de distribution. Aucune configuration de sshd_config n’y pouvait rien.

regreSSHion (CVE-2024-6387, juillet 2024, publiée par Qualys) est une condition de course dans le gestionnaire de signal de sshd, déclenché à l’expiration de LoginGraceTime. Ce gestionnaire appelait des fonctions non sûres en contexte de signal. Il s’agit de la régression d’une faille corrigée en 2006 (CVE-2006-5051). Elle permet une exécution de code à distance, sans authentification et en root, sur Linux avec glibc ; OpenSSH 8.5p1 à 9.7p1 est concerné, avec une correction en 9.8p1. L’exploitation démontrée demande de nombreuses tentatives. Le contournement temporaire LoginGraceTime 0 supprime la course, mais permet d’épuiser les connexions non authentifiées (MaxStartups). On échange une exécution de code contre un déni de service, ce qui reste une bonne affaire jusqu’au correctif.

Ces trois incidents partagent une morale : un sshd exposé à Internet est une surface de pré-authentification. Le faire écouter uniquement derrière un bastion ou un VPN réduit d’un coup l’exposition à toutes les failles futures du même genre.

Durcissement d’OpenSSH côté serveur et côté client

Côté serveur, la ligne à tenir :

clés seulement : PasswordAuthentication no, KbdInteractiveAuthentication no, et AuthenticationMethods publickey pour l’expliciter ;
PermitRootLogin no : on se connecte en nominatif, puis on élève ses privilèges via sudo, ce qui laisse une trace attribuable ;
comptes autorisés limités par AllowGroups ou AllowUsers ;
algorithmes fixés explicitement (KexAlgorithms, Ciphers, MACs, HostKeyAlgorithms, PubkeyAcceptedAlgorithms) sur des listes modernes. Il faut vérifier avec ssh -Q que chaque nom existe dans la version déployée, sinon sshd refuse de démarrer ;
redirections, agent et X11 coupés par défaut (DisableForwarding yes), puis rouverts par Match là où c’est voulu ;
LogLevel VERBOSE, qui journalise l’empreinte de la clé utilisée à chaque connexion : sans cela, on sait qui s’est connecté au sens du compte, mais pas avec quelle clé ;
MaxAuthTries et LoginGraceTime bas, écoute restreinte (ListenAddress) au réseau d’administration.

Le guide Durcir un serveur Linux avant la mise en production couvre le reste de la machine. Côté client, StrictHostKeyChecking ne doit jamais valoir no. Les entrées Host doivent porter ProxyJump plutôt que ForwardAgent, et la commande ssh -G hôte affiche la configuration réellement appliquée, ce qui évite de deviner quel bloc Host a gagné.

Exemple de configuration sshd durcie et vérification

Fichier déposé dans /etc/ssh/sshd_config.d/ (inclus par défaut sur les distributions récentes ; à vérifier avec la directive Include du fichier principal). Les noms d’algorithmes supposent OpenSSH 9.9 ou ultérieur.

# Authentification : clés uniquement, pas de root
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowGroups ssh-admins sftp-depot

# Cryptographie moderne (vérifier avec ssh -Q kex / cipher / mac)
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Pas de redirections, d'agent ni de X11 par défaut
DisableForwarding yes
PermitTunnel no

# Pré-authentification courte, journalisation de l'empreinte
LoginGraceTime 30
MaxAuthTries 3
LogLevel VERBOSE

# Compte de dépôt : SFTP seul, enfermé
Match Group sftp-depot
    ForceCommand internal-sftp
    ChrootDirectory /srv/depot/%u

Avant tout rechargement :

sshd -t                                   # valide la syntaxe, échoue sur un algorithme inconnu
sshd -T | grep -Ei 'kexalgorithms|permitrootlogin|disableforwarding'   # configuration effective
ssh -o BatchMode=yes admin@192.168.20.15 true   # tester depuis une seconde session encore ouverte

Sur un serveur antérieur à OpenSSH 9.9, mlkem768x25519-sha256 n’existe pas et sshd -t le signale. Il faut retirer ce nom plutôt que le service. La session déjà ouverte n’est pas coupée par un rechargement : la garder jusqu’à la validation du test évite le déplacement en salle machine.

Prérequis, garanties absentes et exploitation d’un parc SSH

Prérequis. Il faut une version d’OpenSSH maintenue, au minimum 9.6 pour strict kex et 9.8p1 pour regreSSHion, ou un rétroportage de distribution vérifié. Il faut aussi une heure système fiable pour les certificats (voir DNS, DHCP et NTP), un référentiel des empreintes de clés d’hôte, et un jeton FIDO de secours par administrateur.

Ce que SSH ne garantit pas. Il ne dit rien de ce que fait l’utilisateur une fois authentifié : l’autorisation fine relève de sudo, de ForceCommand ou d’un bastion qui enregistre les sessions. Il ne protège pas un serveur dont la chaîne de bibliothèques est compromise (xz-utils). Il n’empêche pas l’usage légitime d’une clé volée. Enfin, retirer une clé ou révoquer un certificat ne coupe pas les sessions déjà établies : il faut les tuer explicitement.

Exploitation. La rotation des clés utilisateur reste impossible sans inventaire. Il faut donc collecter les fichiers authorized_keys du parc, et lever une alerte à chaque apparition d’une clé qui n’est pas passée par l’outil de déploiement, car c’est le premier geste de persistance d’un attaquant. La supervision repose sur les journaux de sshd, à corréler entre bastion et cibles grâce à l’empreinte journalisée. Les clés d’hôte doivent être sauvegardées avec le même soin qu’une clé privée de serveur web. Une reconstruction qui les régénère déclenche une vague d’alertes d’empreinte, et la vague suivante, celle d’une vraie interception, passera inaperçue.

🐝 Ce qui arrive si on s’en passe

Sans SSH, l’administration à distance repasse par Telnet, rlogin, rsh ou FTP, qui font circuler identifiants et commandes en clair. Il suffit d’une position d’écoute sur le chemin (port miroir, réseau sans fil partagé, équipement intermédiaire compromis) pour capturer le mot de passe d’un compte d’administration, qui reste ensuite réutilisable tant qu’il n’a pas été changé. Ces flux ne sont pas protégés en intégrité : un attaquant peut donc injecter des commandes dans une session TCP déjà ouverte, après l’authentification légitime, sans connaître aucun secret. Les commandes r* accordent leur confiance selon l’adresse source (fichiers .rhosts et hosts.equiv), ce qu’une usurpation d’adresse sur le réseau local suffit à contourner. Enfin, le serveur ne prouve jamais son identité : une machine qui a pris son adresse reçoit les identifiants de l’opérateur sans qu’aucune alerte ne se déclenche.

🦫 Explication de la marmotte 🍫

SSH permet de commander un ordinateur à distance à travers Internet, sans que les personnes qui observent le réseau puissent lire ou modifier ce qui passe. Tout commence par une négociation : l’ordinateur de l’utilisateur et le serveur fabriquent ensemble une clé secrète que personne d’autre ne connaît, puis chiffrent tout avec elle. Le serveur prouve ensuite son identité en signant avec une clé qui lui est propre, sa clé d’hôte. À la première connexion, l’utilisateur doit accepter cette clé ; son ordinateur la mémorise, puis refuse plus tard toute clé différente. Si la clé change, cela signifie soit que le serveur a été réinstallé, soit qu’un intrus se fait passer pour lui : il faut vérifier avant de continuer. Vient ensuite le tour de l’utilisateur. Un mot de passe se devine ou se vole, alors on préfère une paire de clés, voire une petite clé physique qu’il faut toucher. Une fois connecté, on peut ouvrir plusieurs conversations dans le même tuyau : un terminal, une copie de fichiers, ou le relais d’une connexion vers une autre machine. Ce relais permet aussi de traverser les barrières du réseau, ce que les attaquants exploitent. Des failles ont existé dans le logiciel lui-même et dans des bibliothèques qu’il charge. Il faut donc le mettre à jour, n’accepter que les clés, interdire le compte administrateur, couper les relais inutiles et noter qui se connecte avec quelle clé.

Pages voisines

La citent

Protocole SSH, clés d'hôte, authentification et durcissement

Elle cite

: les deux pages se citent l’une l’autre.