Établissement de liaison SSH et authentification par clé d’hôte

SSH commence par établir une connexion TCP vers le port 22. Une fois la connexion établie, le client et le serveur échangent des chaînes de version telles que SSH-2.0-OpenSSH_9.3, qui identifie la version du protocole et l’implémentation. Cet échange de versions permet aux deux parties de confirmer leur compatibilité avant de poursuivre.

Après l’échange de versions, les deux parties envoient des paquets SSH_MSG_KEXINIT qui répertorient les algorithmes pris en charge. Ces listes couvrent les méthodes d’échange de clés, les types de clés d’hôte, les chiffrements symétriques, les algorithmes MAC et la compression. L’intersection des deux listes détermine les algorithmes sélectionnés pour la session.

La clé de session est établie à l’aide d’un algorithme d’échange de clés tel que Diffie-Hellman ou ECDH. Le client et le serveur génèrent chacun une paire de clés éphémères, échangent leurs valeurs publiques et calculent indépendamment le même secret partagé. Ce secret partagé sert de base à la dérivation de la clé de session sans jamais être transmis directement.

Le serveur prouve son identité en signant le hachage de l’échange de clés à l’aide de sa clé privée d’hôte. La clé d’hôte peut être une clé RSA, ECDSA ou au format Ed25519 moderne. Le client utilise la clé publique correspondante pour vérifier cette signature, confirmant qu’il communique bien avec le véritable serveur et non avec un imposteur.

Lors de la première connexion à un nouveau serveur, le client ne connaît pas encore la clé publique de l’hôte. SSH affiche l’empreinte de la clé et invite l’utilisateur à l’accepter. Ce modèle de confiance au premier usage enregistre la clé dans known_hosts et détecte les changements lors des connexions ultérieures, en signalant d’éventuelles attaques de l’homme du milieu.

Le moyen le plus sûr de vérifier une nouvelle clé d’hôte est d’utiliser un canal hors bande. Un administrateur peut lire l’empreinte du serveur en personne ou par l’intermédiaire d’un canal sécurisé vérifié, puis la comparer à celle affichée par le client SSH. Cela évite d’accepter silencieusement une clé frauduleuse lors de la première connexion.

Le fichier known_hosts stocke des lignes de la forme : hostname algorithm base64-key. Chaque entrée représente une identité de serveur approuvée. Lorsque vous vous connectez à un hôte déjà présent dans known_hosts, SSH vérifie que la clé présentée correspond à celle qui est enregistrée et refuse la connexion en cas d’incohérence.

Après l’échange de clés, les deux parties dérivent indépendamment les clés de session à partir du secret partagé, du hachage de l’échange et de l’identifiant de session. Des clés distinctes sont dérivées pour chaque direction de communication et pour le chiffrement comme pour les opérations MAC. Ainsi, les clés utilisées pour le trafic du client vers le serveur diffèrent de celles utilisées du serveur vers le client.

Une fois les clés de session établies, toutes les communications SSH suivantes sont chiffrées et authentifiées. Le chiffrement négocié, tel que AES-256-GCM ou ChaCha20-Poly1305, protège la confidentialité, tandis que le MAC garantit l’intégrité. Même le nom d’utilisateur et les informations d’authentification sont transmis à l’intérieur de ce tunnel chiffré.

Les clés d’hôte RSA de 2048 ou 4096 bits sont largement prises en charge, mais elles sont plus lentes. Les clés ECDSA fondées sur des courbes NIST sont plus rapides, mais certaines personnes n’accordent pas leur confiance aux paramètres des courbes NIST. Les clés Ed25519 fondées sur Curve25519 sont actuellement recommandées : elles sont petites, rapides, offrent un niveau élevé de sécurité et ne dépendent pas des paramètres des courbes NIST. La plupart des serveurs SSH modernes proposent Ed25519 par défaut.

L’échange initial SSH comprend les étapes suivantes : connexion TCP, échange de versions, négociation des algorithmes, échange de clés établissant les clés de session, vérification de la clé d’hôte du serveur et authentification de l’utilisateur. Toutes les étapes suivant l’échange de versions se déroulent au sein d’un canal chiffré dont l’intégrité est protégée, établi pendant la phase d’échange de clés.

Comment un client vérifie-t-il la clé d’hôte du serveur SSH lors des connexions suivantes, après la première ?

Dans cette leçon : une connexion TCP est établie sur le port 22, les chaînes de version sont échangées, la négociation des algorithmes sélectionne les chiffrements et les méthodes d’échange de clés, ECDH ou DH établit un secret partagé, les clés de session sont dérivées séparément pour chaque direction, le serveur s’authentifie à l’aide de la signature de sa clé d’hôte et le client vérifie cette clé par rapport à known_hosts en appliquant TOFU lors de la première connexion.