Histoire de SSH : de telnet à OpenSSH

À l’origine de l’histoire de SSH

L’histoire de SSH commence avec le vol de mots de passe. Avant 1995, se connecter à une machine Unix distante signifiait utiliser telnet ou rlogin. Ces deux protocoles transmettaient le mot de passe sur le réseau en clair. Toute personne capable de surveiller le trafic pouvait le lire. Au début des années 1990, certains le faisaient déjà à grande échelle.

SSH est la réponse d’une personne à ce problème. Le protocole a été écrit en 1995, puis distribué gratuitement. Il a depuis été reconstruit une fois. Le programme utilisé aujourd’hui par presque tout le monde est issu d’un fork d’un fork. Les dates ci-dessous sont importantes, car chaque étape répondait à une défaillance précise.

Ce que telnet et rlogin transmettaient réellement

Telnet est défini dans la RFC 854, publiée en mai 1983 par Jon Postel et Joyce Reynolds. Elle décrit une session de terminal transportée sur TCP et n’intègre aucun chiffrement. Chaque octet saisi, y compris le mot de passe, circule en clair. Tout équipement présent sur le chemin peut le lire.

rlogin est issu de Berkeley Unix et a été documenté plus tard dans la RFC 1282 (BSD Rlogin, B. Kantor, décembre 1991). Il ajoutait un élément plus dangereux encore qu’un mot de passe lisible : la confiance fondée sur l’hôte. Un serveur pouvait être configuré pour accepter les connexions provenant d’un hôte donné, sans demander de mot de passe. La RFC contient une section intitulée « A Cautionary Tale », qui précise : « Le contournement de l’authentification par mot de passe depuis des hôtes de confiance expose TOUS les systèmes ainsi configurés dès qu’un seul d’entre eux est compromis. » Elle précise également que la confiance repose sur les noms d’hôte. Une compromission du DNS (domain name system) ou une adresse usurpée suffit donc à la contourner.

Ces deux conceptions correspondaient au réseau sur lequel elles sont nées. Les premiers réseaux Ethernet utilisaient un support partagé : chaque machine d’un segment recevait chaque trame et devait ignorer celles qui ne lui étaient pas destinées. Une machine qui cessait de les ignorer, ce que signifie le mode promiscuous, voyait le trafic de toutes les autres machines. Ajoutez une université qui attribue des comptes shell à des milliers d’étudiants, et un seul compte compromis pouvait servir à collecter les mots de passe de tout un département.

L’avis de 1994 qui ne proposait aucun correctif

Le 3 février 1994, le CERT a publié l’avis CA-94:01, « Ongoing Network Monitoring Attacks ». Il signalait que des intrus avaient capturé les informations d’accès de dizaines de milliers de systèmes sur Internet. L’outil utilisé plaçait l’interface réseau en mode promiscuous et enregistrait le début de chaque nouvelle session telnet, rlogin et FTP, c’est-à-dire la partie qui contient le nom d’utilisateur et le mot de passe.

Le CERT recommandait aux sites de modifier le mot de passe de chaque compte accessible sur le réseau. Si l’on tient compte du fonctionnement de ces protocoles, le piège est évident : le nouveau mot de passe transite en clair sur le même réseau lors de sa première utilisation. Aucun correctif ne pouvait être intégré à telnet ou rlogin, car aucun de ces protocoles ne prévoyait d’emplacement pour en ajouter un.

Pourquoi une attaque par sniffing à Helsinki a donné naissance à SSH

En 1995, le réseau de l’université de technologie d’Helsinki a subi une attaque par sniffing de mots de passe du type décrit par le CERT. Tatu Ylönen, un chercheur de l’université, a écrit un remplacement et l’a publié comme freeware en juillet 1995. Il l’a appelé Secure Shell.

Deux choix de conception ont assuré son succès. La session était chiffrée : un attaquant qui écoutait le segment ne pouvait rien apprendre d’utile. Le serveur prouvait aussi son identité avec une clé, ce qui permettait au client de vérifier qu’il s’était connecté à la bonne machine. C’est précisément la faille laissée ouverte par la confiance de rlogin envers le hostname.

Le logiciel s’est également répandu parce que ses commandes correspondaient à celles que les utilisateurs saisissaient déjà. ssh remplaçait rsh et rlogin, tandis que scp remplaçait rcp. La migration demandait de changer une habitude, pas un workflow. À la fin de 1995, la base d’utilisateurs comptait environ 20,000 personnes dans cinquante pays. En décembre de la même année, Ylönen a fondé SSH Communications Security pour développer et commercialiser le logiciel.

D’une version libre à un produit commercial

À mesure que SSH est devenu une activité commerciale, la licence du code source a changé. Les versions suivantes comportaient des conditions qui limitaient ce que d’autres personnes pouvaient faire avec le code, et la dernière version que tout le monde pouvait réutiliser librement était ssh 1.2.12. Rien d’irrégulier là-dedans. Cela signifiait simplement que la version de SSH sur laquelle le reste du monde pouvait s’appuyer a cessé d’évoluer, tandis que le développement se poursuivait dans un environnement que ce monde ne pouvait pas suivre. Les licences déterminent quel code perdure, un phénomène décrit dans comment les licences open source ont façonné l’infrastructure moderne.

Pourquoi OpenBSD a créé un fork d’OpenSSH en 1999

Au début de 1999, Björn Grönvall a repris cette dernière version libre et a commencé à en corriger les bugs. Sa version s’appelait OSSH et ne parlait que le protocole SSH 1.3.

Le projet OpenBSD a repris OSSH et l’a reconstruit. D’après le compte rendu du projet, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell et Dug Song ont nettoyé, audité et étendu le code. Le résultat était OpenSSH 1.2.2, publié avec OpenBSD 2.6 le 1 décembre 1999.

Pourquoi le fork d’un petit projet de système d’exploitation s’est-il retrouvé sur presque toutes les machines ? À cause des besoins d’OpenBSD. OpenBSD fournit un système de base audité, conçu pour être sûr avec sa configuration par défaut. La connexion distante chiffrée devait donc faire partie de ce système de base, sous une licence sans restriction. Du code audité sous une licence sans restriction correspondait précisément à ce que recherchaient aussi tous les autres éditeurs de systèmes d’exploitation. Damien Miller, Philip Hands et d’autres ont presque immédiatement commencé une branche portable. C’est de là que vient le p dans une version comme 10.5p1. OpenBSD développe la version propre, tandis que la branche portable ajoute les adaptations nécessaires aux autres systèmes. La façon dont Unix s’est divisé en systèmes que nous utilisons aujourd’hui explique pourquoi ces adaptations sont nécessaires.

La prise en charge de la deuxième version du protocole a suivi. OpenSSH 2.0 a été publié avec OpenBSD 2.7 le 15 juin 2000.

Pourquoi SSH-2 est un nouveau protocole et non une simple révision

SSH-1 protégeait l’intégrité du flux chiffré avec CRC-32, une somme de contrôle conçue pour détecter les erreurs de transmission, pas pour résister à un attaquant. En 1998, Ariel Futoransky et Emiliano Kargieman, de CORE SDI, ont montré ce que cela impliquait. Avec les modes de chiffrement CBC ou CFB et une vérification CRC-32, un attaquant qui connaît seulement 16 octets du texte en clair peut insérer un texte chiffré de son choix que le destinataire accepte comme authentique, ce qui permet d’exécuter des commandes sur le serveur.

La faille se trouvait dans le protocole. Elle ne pouvait donc pas être corrigée sans casser la compatibilité. Les implémentations ont ajouté un détecteur à la place : du code dans un fichier appelé deattack.c qui tentait de reconnaître l’attaque pendant son déroulement. En février 2001, ce détecteur s’est révélé contenir son propre dépassement d’entier, CVE-2001-0144, permettant l’exécution de code à distance contre les serveurs et les clients qui incluaient le correctif. Une conception qui ne peut pas être réparée accumule les correctifs, et ces correctifs introduisent leurs propres bugs.

SSH-2 a été défini par un groupe de travail de l’IETF nommé secsh, puis publié sous forme de RFC en janvier 2006 : l’architecture dans la RFC 4251, la couche de transport dans la RFC 4253, l’authentification des utilisateurs dans la RFC 4252 et la couche de connexion dans la RFC 4254. La séparation en couches est l’élément important, car chaque couche peut ensuite être remplacée indépendamment. Le reste de cette histoire décrit principalement ces remplacements.

Deux changements sont particulièrement importants. L’intégrité est passée de CRC-32 à un HMAC (code d’authentification de message fondé sur un condensat) utilisant une clé dérivée d’un secret partagé. Un attaquant qui ne peut pas calculer le MAC ne peut donc pas falsifier un paquet. L’accord de clé est également passé à Diffie-Hellman. Dans SSH-1, le client choisissait la clé de session et l’envoyait chiffrée avec les clés RSA du serveur. Toute personne qui obtenait ultérieurement ces clés privées pouvait donc déchiffrer une session enregistrée. Diffie-Hellman dérive un secret différent pour chaque session. Ce secret n’est jamais transmis. Enregistrer le trafic, puis voler la clé d’hôte, ne permet donc plus rien. Cette propriété s’appelle la confidentialité persistante.

SSH-2 n’est pas compatible au niveau du protocole avec SSH-1. C’est pourquoi le nombre a changé, plutôt que le simple numéro décimal.

Pourquoi SSH-1 a été supprimé plutôt que corrigé

La suppression s’est faite en trois versions d’OpenSSH. La version 7.0, publiée le 11 août 2015, a désactivé le protocole 1 par défaut lors de la compilation. La version 7.4, publiée le 19 décembre 2016, a supprimé sa prise en charge côté serveur. La version 7.6, publiée le 3 octobre 2017, a également supprimé le côté client, ainsi que ses options de configuration et sa documentation.

Le conserver comme option pour les équipements anciens aurait été un choix plus souple. Le détecteur CRC-32 explique pourquoi ce choix a été écarté. Le dépassement n’était exploitable que parce que le code du protocole 1 était compilé. Il se trouvait dans un chemin d’exécution que la plupart des administrateurs pensaient inactif sur leurs systèmes. Du code livré peut être atteint. Du code supprimé ne le peut pas.

Pourquoi votre première connexion SSH signale la clé d’hôte

Le chiffrement garantit la confidentialité du trafic. Il ne garantit pas l’identité de l’autre extrémité. Si un attaquant intercepte le trafic et répond à la place de votre serveur, vous obtenez une session parfaitement chiffrée avec l’attaquant. Il s’agit d’une attaque de type machine-in-the-middle. SSH répond à ce problème avec une clé d’hôte : le serveur prouve qu’il détient la clé privée d’une paire de clés, puis le client compare cette clé avec celle qu’il a enregistrée précédemment. Pour comprendre le fonctionnement de la connexion elle-même, consultez ce qui se passe lorsque vous ouvrez une connexion SSH.

Lors de la première connexion, aucune valeur précédente n’existe. Le client n’a donc rien à comparer et doit vous demander :

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Répondre yes enregistre cette clé dans ~/.ssh/known_hosts. Lors de chaque connexion suivante, la clé est comparée à la valeur enregistrée. Une différence produit le message le plus alarmant du programme :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

La première invite signifie honnêtement que le protocole reconnaît son unique moment de faiblesse. Avec le modèle trust on first use, la sécurité de la première connexion dépend entièrement du réseau utilisé. Vous pouvez réduire ce risque. Lisez l’empreinte depuis la console de votre fournisseur ou le journal de build du serveur avant de vous connecter. Publiez-la dans le DNS sous forme d’enregistrement SSHFP (RFC 4255), mais cette méthode n’est utile que si vous utilisez DNSSEC. Vous pouvez aussi signer les clés d’hôte avec votre propre autorité de certification (CA), afin que les clients fassent confiance à la CA plutôt qu’à chaque clé individuelle. En pratique, la plupart des utilisateurs acceptent l’invite sans vérification. Il est préférable de le reconnaître clairement.

Pourquoi les clés publiques ont remplacé les mots de passe

L’authentification par clé publique existe depuis les premières versions de SSH, mais il a fallu des années pour qu’elle devienne la méthode habituelle. Le mécanisme est asymétrique : le client prouve qu’il détient une clé privée en signant un défi, et la clé privée ne quitte jamais le client. Un mot de passe fonctionne à l’inverse. Même si SSH le transporte dans le canal chiffré, le serveur reçoit le secret lui-même. Un serveur compromis ou malveillant détient donc une donnée qu’il peut réutiliser contre vous ailleurs.

La deuxième raison est mathématique. Tout serveur dont le port 22 est ouvert sur une adresse publique reçoit des tentatives de connexion automatisées jour et nuit, et un mot de passe est une chaîne devinable. Une clé ne peut pas être devinée en pratique. La configuration de PasswordAuthentication no élimine toute cette catégorie d’attaques, ce qui explique sa présence dans toutes les listes de vérification de renforcement de la sécurité. La génération et la rotation des clés sont présentées dans Notions de base sur la gestion des clés SSH, et les paramètres côté serveur dans Renforcer la sécurité de SSH sur un VPS.

Pourquoi la liste des algorithmes SSH change régulièrement

Un protocole en couches permet de retirer des algorithmes sans créer un nouveau protocole. OpenSSH utilise cette possibilité de manière continue, comme le montrent les dates de sortie.

Ed25519 est arrivé dans OpenSSH 6.5, le 30 janvier 2014, avec le chiffrement chacha20-poly1305 et un format de clé privée protégé par bcrypt. Les signatures Ed25519 dérivent leur nonce par signature de manière déterministe. Un générateur de nombres aléatoires faible au moment de la signature ne peut donc pas divulguer la clé privée. C’est exactement ainsi que des clés privées DSA et ECDSA ont été récupérées lors d’incidents réels.

DSA a suivi la trajectoire inverse. OpenSSH 7.0 a désactivé ssh-dss les clés d’hôte et les clés utilisateur à l’exécution en 2015, car cet algorithme est limité à une clé privée de 160 bits et à SHA-1. La version 9.8, le 1 juillet 2024, a désactivé DSA à la compilation. La version 10.0, le 9 avril 2025, l’a supprimé, selon les termes du projet, « achevant le processus d’obsolescence commencé en 2015 ». Dix ans entre la désactivation et la suppression.

RSA n’a pas disparu, mais son ancien format de signature, lui, a disparu. OpenSSH 8.8, le 26 septembre 2021, a cessé d’accepter par défaut les signatures RSA produites avec SHA-1. Les notes de version exposent clairement la raison : SHA-1 est cassé du point de vue cryptographique, et des collisions à préfixe choisi pouvaient être produites pour moins de 50,000 USD. Si vous avez déjà rencontré sign_and_send_pubkey: no mutual signature supported en vous connectant à un ancien serveur, c’est ce changement qui en est la cause. Votre clé est valide. L’algorithme de signature demandé par l’autre extrémité ne l’est pas.

Le même processus concerne maintenant l’échange de clés, cette fois avant que la menace ne se concrétise. Le trafic capturé aujourd’hui peut être stocké, puis déchiffré des années plus tard par la personne qui disposera la première d’un ordinateur quantique suffisamment puissant. L’accord de clé devait donc évoluer avant l’existence d’une telle machine. OpenSSH 9.0, le 8 avril 2022, a fait d’un échange de clés hybride le comportement par défaut : sntrup761x25519-sha512@openssh.com associe un algorithme post-quantique à l’échange X25519. Le résultat n’est ainsi pas plus faible que la partie classique si le nouvel algorithme présente une faiblesse. OpenSSH 9.9, le 19 septembre 2024, a ajouté mlkem768x25519-sha256, fondé sur ML-KEM (mécanisme d’encapsulation de clés sur réseau de modules), standardisé par le NIST en 2024. OpenSSH 10.0 en a fait le comportement par défaut pour l’accord de clé, et la page post-quantique du projet explique le raisonnement. OpenSSH 10.1, le 6 octobre 2025, a commencé à afficher un avertissement lorsque l’autre extrémité ne le prend pas en charge :

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Cet avertissement est activé par défaut et contrôlé par l’option WarnWeakCrypto dans ssh_config. Sa signification pratique et la conduite à tenir lorsqu’un serveur le déclenche sont expliquées dans les valeurs par défaut de l’échange de clés SSH post-quantique.

Ce que cet historique implique pour le serveur devant vous

La commande que vous saisissez a à peine changé depuis 1995. Presque tout ce qui se trouve dessous a été remplacé : le contrôle d’intégrité, l’échange de clés, les algorithmes de signature et le code lui-même. Cela n’a été possible que parce que chaque remplacement s’est terminé par une suppression délibérée, et que chaque suppression a rendu quelque chose incompatible pour certains utilisateurs.

Votre sécurité SSH dépend donc principalement de votre version. Les valeurs par défaut déterminent les algorithmes proposés, ceux qui sont refusés et les avertissements affichés. Un serveur ancien continue de proposer les algorithmes encore autorisés par sa version et négocie à la baisse pour rester compatible avec un ancien client. En août 2026, la version actuelle est OpenSSH 10.5, publiée le 11 août 2026. L’écart entre cette version et celle installée sur une machine qui n’a pas été touchée depuis trois ans donne la mesure du problème. Sa vérification doit faire partie des dix premières minutes sur un nouveau VPS.

FAQ

Qui a créé SSH et pourquoi ?

Tatu Ylönen, chercheur à l’université de technologie d’Helsinki, a écrit SSH en 1995 après une attaque par interception de mots de passe sur le réseau de l’université. Les outils de connexion à distance de l’époque, telnet et rlogin, envoyaient les mots de passe sur le réseau en clair. Toute personne qui surveillait un segment partagé pouvait donc récupérer les identifiants lors de leur transmission. Il a publié le programme comme freeware en juillet 1995. À la fin de cette année, le programme comptait environ 20,000 utilisateurs dans cinquante pays. En décembre 1995, il a fondé SSH Communications Security.

Quelle est la différence entre SSH-1 et SSH-2 ?

Ce sont deux protocoles différents, sans compatibilité au niveau du wire protocol. SSH-1 était un protocole monolithique qui utilisait CRC-32 pour l’intégrité. Le client envoyait une clé de session chiffrée avec les clés RSA du serveur. SSH-2 sépare le fonctionnement en une couche de transport, une couche d’authentification et une couche de connexion (RFCs 4251 à 4254, janvier 2006). Il utilise un HMAC pour l’intégrité et dérive les clés de session avec Diffie-Hellman. Le trafic enregistré reste ainsi confidentiel même si la clé de l’hôte est volée ultérieurement. SSH-1 a été progressivement retiré d’OpenSSH, jusqu’à sa suppression définitive dans la version 7.6 en octobre 2017.

Pourquoi OpenSSH a-t-il remplacé l’implémentation SSH originale ?

Le développement de l’implémentation originale a évolué vers un produit commercial soumis à une licence restrictive. La dernière release librement réutilisable était ssh 1.2.12. Début 1999, Björn Grönvall a repris cette release sous le nom OSSH. L’équipe OpenBSD a ensuite forké OSSH pour créer OpenSSH, intégré à OpenBSD 2.6 le 1 décembre 1999. OpenBSD avait besoin, pour son système de base, d’un code audité distribué sous une licence sans restriction. Ces deux caractéristiques ont permis à tous les autres systèmes d’exploitation de distribuer la même implémentation via la branche portable.

Pourquoi SSH demande-t-il la clé de l’hôte lors de la première connexion ?

Parce que le client n’a encore jamais vu ce serveur et n’a aucune clé de référence avec laquelle comparer sa clé. Le chiffrement seul ne permet pas de distinguer un serveur légitime d’une machine placée au milieu du chemin réseau. SSH identifie donc les serveurs par leur clé et enregistre ce qu’il a observé dans ~/.ssh/known_hosts. Lors de la première connexion, aucune valeur enregistrée ne permet d’effectuer la vérification. Le client vous demande donc de confirmer la clé. Comparez l’empreinte avec celle fournie par la console du fournisseur ou par le serveur lui-même. Considérez tout message ultérieur REMOTE HOST IDENTIFICATION HAS CHANGED comme un événement réel tant que vous ne pouvez pas l’expliquer.

Pourquoi d’anciennes clés SSH cessent-elles de fonctionner après une mise à niveau ?

Parce qu’OpenSSH retire les algorithmes selon un calendrier publié. Les clés DSA (ssh-dss) ont été désactivées par défaut dans OpenSSH 7.0 en 2015, puis supprimées dans OpenSSH 10.0 le 9 avril 2025. Les clés RSA fonctionnent toujours, mais les signatures produites avec SHA-1 ont été désactivées par défaut dans OpenSSH 8.8 en septembre 2021. Ce problème apparaît sous la forme de sign_and_send_pubkey: no mutual signature supported lorsque vous vous connectez à un ancien serveur. Une clé Ed25519, disponible depuis OpenSSH 6.5 en janvier 2014, évite ces deux problèmes.