Résumé

  • Le premier échange de clés produit un secret partagé K et un hachage H. Ce premier H, dérivé de la négociation réelle, devient l’identifiant de la connexion.
  • Un nouvel échange peut remplacer algorithmes, clés de trafic, vecteurs d’initialisation, contextes et même clé d’hôte ; l’identifiant de session initial, lui, ne change pas.
  • L’authentification par clé publique signe cet identifiant avec la demande précise d’utilisateur et de service. Elle empêche la réutilisation dans une autre connexion, mais ne décide pas quels canaux ou commandes le serveur autorisera.

Renouveler la protection sans recommencer la conversation

Une session distante longue vit selon deux horloges. Le terminal, le transfert de fichiers et les redirections doivent conserver leur état. Les clés de chiffrement, au contraire, gagnent à être renouvelées avant la fin de cette activité.

Faire de chaque renouvellement une nouvelle session obligerait les couches supérieures à tout reconstruire. Considérer chaque nouvelle clé comme une identité indépendante rendrait au contraire l’authentification antérieure difficile à rattacher au trafic protégé après le changement.

La RFC 4251 fournit la séparation décisive. Le transport authentifie le serveur et protège le flux. Le protocole d’authentification établit l’utilisateur côté client. Le protocole de connexion ouvre plusieurs canaux logiques au-dessus. Le remplacement des clés appartient au premier niveau ; l’autorisation d’un shell ou d’un transfert demeure plus haut.

Il fallait donc un repère qui traverse les changements de protection, sans devenir pour autant une identité mondiale du serveur ou de l’utilisateur.

Le repère naissait du transcript, pas d’une déclaration

Les deux extrémités envoient SSH_MSG_KEXINIT. Chacune fournit un cookie aléatoire et ses listes ordonnées de méthodes pour l’échange de clés, la clé d’hôte, le chiffrement, l’intégrité et la compression. La sélection part de la préférence du client et retient le premier choix également pris en charge par le serveur.

La méthode choisie produit ensuite un secret partagé K et un hachage d’échange H. Dans la construction Diffie–Hellman historique de SSH version 2, ce hachage inclut les chaînes d’identification du client et du serveur, leurs deux paquets KEXINIT bruts, la clé publique d’hôte, les valeurs éphémères et le secret partagé.

Une proposition d’algorithme modifiée, une autre clé d’hôte ou une nouvelle valeur éphémère donne donc un autre transcript. Le hachage n’est ni un numéro de ticket fourni par le serveur, ni un nom choisi par le client. Les deux parties contribuent à la valeur, et aucune ne peut prétendre seule qu’une autre conversation est la même.

Le serveur signe H avec la clé d’hôte négociée. Cette signature prouve que le détenteur de la clé privée a signé cet échange. Elle ne prouve pas encore que cette clé appartient au nom d’hôte visé. C’est au client d’appliquer son modèle de confiance : association déjà enregistrée, certificat, empreinte vérifiée ou autre politique. Une signature exacte faite par une clé étrangère reste une mauvaise destination.

Le premier H reçut une fonction supplémentaire

La RFC 4253 utilise chaque échange pour dériver clés et vecteurs. Mais seul le premier hachage devient aussi session_id. Une fois établi, cet identifiant ne change plus pendant cette connexion.

Le contraste avec le rekey est volontaire. L’une ou l’autre extrémité peut le déclencher. Les méthodes négociées peuvent changer, toutes les clés sont recalculées, les contextes de chiffrement et de compression sont réinitialisés, et même la clé d’hôte peut différer. L’échange produit encore un nouveau K et un nouveau H, utiles à la nouvelle protection. Il ne réécrit pas l’identifiant hérité du commencement.

Cette règle ne signifie pas que les changements sont sans conséquence. Une clé d’hôte inattendue demande une décision de confiance ; une méthode faible peut violer la politique ; un échec coupe la connexion. Elle affirme seulement qu’un renouvellement réussi du transport ne crée pas, de lui-même, une nouvelle conversation pour les protocoles supérieurs.

Une reconnexion est différente. Après la perte du transport, un nouvel échange initial produit un autre identifiant. Une application peut reprendre une copie ou rattacher un terminal par son propre mécanisme, mais cette reprise ne transforme pas deux connexions SSH en une seule identité cryptographique.

La signature utilisateur nommait la session et la demande

La RFC 4252 lie la preuve de possession utilisateur à ce contexte. Pour la méthode publickey, la signature ne porte pas seulement sur la clé ou le nom de compte. Les octets signés commencent par l’identifiant de session, puis contiennent le numéro du message, l’utilisateur, le service, le nom de méthode, un booléen, l’algorithme de clé publique et la clé elle-même.

Copier la signature dans une autre connexion ne fonctionne pas : le premier hachage y est différent. Changer le compte, le service ou l’algorithme modifie également l’énoncé signé. La preuve répond donc à une question étroite : cette clé privée a-t-elle approuvé cette demande précise dans ce transport précis ?

Le serveur conserve pourtant plusieurs décisions. Il vérifie la signature, détermine si la clé est acceptable pour l’utilisateur annoncé et applique éventuellement d’autres facteurs. Une signature valide peut mener à un échec parce que la clé n’est pas autorisée, parce qu’une seconde méthode reste obligatoire ou parce que le service demandé n’est pas admis.

L’authentification fondée sur l’hôte reprend la même liaison, avec en plus le nom du client et l’utilisateur sur cette machine. Là encore, possession de la clé, correspondance du nom et droit de connexion restent trois contrôles.

Un succès d’authentification ne gouvernait pas tous les usages

SSH_MSG_USERAUTH_SUCCESS termine la politique d’authentification appliquée à cet instant. Il ne préautorise pas tous les effets futurs. Le serveur doit encore décider si le compte peut ouvrir un shell, lancer un sous-système, demander une redirection de port, utiliser un agent ou atteindre une destination donnée.

Certaines permissions ne peuvent être évaluées plus tôt : lors du login, le client n’a pas encore décrit tous ses canaux. L’identifiant de session apporte donc une continuité de preuve, non un pouvoir général. Il rattache une authentification à la bonne connexion ; il n’abolit pas les décisions locales qui suivent.

Une trace d’audit qui ne garde que « clé publique acceptée » et session_id sait corréler un login. Sans les décisions de canal, elle ne sait pas quelles commandes ont été admises, quels ports ont été ouverts ni quel sous-système a réellement servi des données.

Les algorithmes changèrent, la séparation resta

L’architecture de 2006 devait survivre au vieillissement de ses choix cryptographiques. La RFC 8332 introduisit les signatures RSA avec SHA-256 et SHA-512 pour l’authentification du serveur comme du client. Une même clé RSA encodée au format historique pouvait être employée avec un nouvel algorithme de signature : la matière de clé, la procédure de signature et le message signé restaient séparables.

La RFC 9142 révisa ensuite les recommandations des méthodes KEX et poussa la sortie des variantes fondées sur SHA-1. Ce changement de cycle de vie n’exigea pas de rendre l’identifiant mobile. Un nouvel algorithme pouvait produire l’échange initial ; son premier hachage gardait la même fonction architecturale.

La continuité ne guérit toutefois pas un mauvais début. Si la clé d’hôte a été mal vérifiée ou si un échange trop faible a été accepté, les preuves suivantes restent solidement attachées à ce contexte défectueux. Lier n’est pas valider rétroactivement.

Cinq identités apparentes, cinq responsabilités

Nom d’hôte, clé d’hôte, hachage d’échange, identifiant de session et clé utilisateur sont parfois affichés sous une seule étiquette « identité SSH ». Le nom désigne la destination attendue. La clé d’hôte est un principal cryptographique à relier à ce nom. Le hachage décrit un échange. Son premier exemplaire identifie une connexion. La clé utilisateur prouve une possession pour une demande donnée.

Aucun de ces objets ne remplace la politique d’autorisation ni la preuve d’une action applicative. Les RFC établissent le mécanisme et son évolution, pas la qualité des configurations réelles, la fréquence des rekeys, la disparition universelle de SHA-1 ou l’exécution d’une commande particulière.

SSH a ainsi choisi une invariance limitée : les clés pouvaient changer, mais les preuves supérieures conservaient le droit de désigner le même commencement. Le hachage resté en place n’était pas une autorité ; c’était un contexte vérifiable.