Histoire de SSH : de telnet à OpenSSH

Aux origines de SSH

L’histoire de SSH commence avec des mots de passe volés. Avant 1995, se connecter à une machine Unix distante signifiait utiliser telnet ou rlogin, qui transmettaient tous deux le mot de passe sur le réseau en clair. Toute personne capable de surveiller le trafic pouvait le lire, et au début des années 1990, c’est exactement ce que certains faisaient, à 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 été entièrement reconstruit une fois depuis, et le programme utilisé aujourd’hui par presque tout le monde est 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 ne prévoit aucun chiffrement. Chaque octet saisi, y compris le mot de passe, circule en clair. Tout équipement situé sur le chemin peut le lire.

rlogin est issu de Berkeley Unix et a été décrit plus tard dans la RFC 1282 (BSD Rlogin, B. Kantor, décembre 1991). Il ajoutait un mécanisme plus risqué qu’un mot de passe lisible : la confiance fondée sur l’hôte. Un serveur pouvait être configuré pour accepter sans mot de passe les connexions provenant d’un hôte donné. La RFC contient une section intitulée « A Cautionary Tale » qui indique : « 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 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 avaient été créé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 l’on appelle le mode promiscuous, voyait le trafic des autres machines. Ajoutez une université qui attribue des comptes shell à des milliers d’étudiants, et un seul compte compromis pouvait servir à récupérer 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 par le réseau. Si l’on tient compte du fonctionnement de ces protocoles, le problème est évident : le nouveau mot de passe traverse le même câble en clair 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 conduit à SSH

En 1995, le réseau de l’université technologique d’Helsinki a subi une attaque par interception de mots de passe du type décrit par le CERT. Tatu Ylönen, chercheur dans cette 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 fonctionnement. La session était chiffrée : un attaquant qui écoutait le segment n’apprenait rien d’exploitable. Le serveur prouvait aussi son identité avec une clé. Le client pouvait donc vérifier qu’il s’était connecté à la bonne machine. C’est précisément la faille laissée ouverte par la confiance accordée au nom d’hôte par rlogin.

Le logiciel s’est également diffusé parce que les commandes correspondaient à celles que les utilisateurs saisissaient déjà. ssh remplaçait rsh et rlogin, tandis que scp remplaçait rcp. Le changement ne demandait qu’une nouvelle habitude, pas une nouvelle méthode de travail. À la fin de 1995, la base d’utilisateurs atteignait environ 20,000 utilisateurs 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

Lorsque 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. La dernière version que chacun pouvait réutiliser librement était ssh 1.2.12. Cela n’avait rien d’irrégulier. Cela signifiait simplement que la version de SSH sur laquelle le reste du monde pouvait continuer à s’appuyer n’évoluait plus, tandis que le développement se poursuivait dans un environnement inaccessible à ce monde. Les licences déterminent quel code perdure. Ce point mérite d’être approfondi dans la manière dont 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 est reparti de 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 récit 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, fourni 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 répondait précisément aux besoins de tous les autres éditeurs de systèmes d’exploitation. Damien Miller, Philip Hands et d’autres ont commencé presque immédiatement 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 pour tout le reste. La manière 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é fourni avec OpenBSD 2.7 le 15 juin 2000.

Pourquoi SSH-2 est un nouveau protocole et non une simple nouvelle version

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é les conséquences de cette conception. Avec les modes de chiffrement CBC ou CFB et une vérification CRC-32, un attaquant qui connaît aussi peu que 16 octets du texte en clair peut injecter un texte chiffré choisi que le récepteur accepte comme authentique. Il peut ainsi exécuter des commandes sur le serveur.

La faille se trouvait dans le protocole. Elle ne pouvait donc pas être corrigée sans rompre la compatibilité. Les implémentations ont ajouté un détecteur à la place, sous la forme de code dans un fichier nommé deattack.c, qui tentait de reconnaître l’attaque au moment où elle se produisait. En février 2001, ce détecteur s’est révélé contenir son propre dépassement d’entier, CVE-2001-0144. Cette faille permettait l’exécution de code à distance contre les serveurs et les clients qui avaient reçu 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 le point essentiel, car chaque couche peut ensuite être remplacée indépendamment. La majeure partie de la suite de cette histoire est celle de 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 une fonction de hachage) utilisant un secret partagé comme clé. 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 ensuite ces clés privées pouvait donc déchiffrer une session enregistrée. Diffie-Hellman dérive un nouveau secret pour chaque session. Ce secret n’est jamais transmis. Enregistrer le trafic, puis dérober la clé d’hôte plus tard, ne permet donc plus rien. Cette propriété s’appelle la perfect forward secrecy.

SSH-2 ne partage aucune compatibilité au niveau du protocole avec SSH-1. C’est pourquoi le numéro a changé, plutôt que la décimale.

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

La suppression s’est étendue sur trois versions d’OpenSSH. La version 7.0, le 11 August 2015, a désactivé le protocole 1 par défaut lors de la compilation. La version 7.4, le 19 December 2016, a supprimé sa prise en charge côté serveur. La version 7.6, le 3 October 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é le choix le plus simple pour les utilisateurs, mais le détecteur CRC-32 explique pourquoi cette option a été écartée. Le dépassement de capacité n’était exploitable que parce que le code du protocole 1 était compilé, et il se trouvait dans un chemin que la plupart des administrateurs pensaient inactif sur leurs systèmes. Tout code livré peut être atteint. Le code supprimé ne le peut pas.

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

Le chiffrement garantit la confidentialité du trafic. Il ne vous indique pas qui se trouve à l’autre extrémité. Si un attaquant s’interpose sur le trajet 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 partie 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 connaître le déroulement de la connexion elle-même, consultez ce qui se passe lors de l’ouverture d’une connexion SSH.

Lors de la première connexion, il n’existe aucun enregistrement précédent. 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. En cas de différence, le programme affiche son message le plus important :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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. Le principe de confiance lors de la première utilisation signifie que 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’un enregistrement SSHFP (RFC 4255), ce qui 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 effectuer de vérification. Il est préférable de le reconnaître clairement.

Comment les clés publiques ont relégué les mots de passe au second plan

L’authentification par clé publique existait dès les premières versions de SSH, mais il a fallu des années pour qu’elle devienne la pratique habituelle. Le mécanisme est asymétrique : le client prouve qu’il détient une clé privée en signant un challenge, et la clé privée ne quitte jamais le client. Avec un mot de passe, c’est 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 quelque chose qu’il peut réutiliser contre vous ailleurs.

La deuxième raison est arithmétique. Tout serveur dont le port 22 est ouvert sur une adresse publique reçoit en permanence des tentatives de connexion automatisées, et un mot de passe est une chaîne devinable. Une clé ne peut pas être devinée dans la pratique. L’activation de PasswordAuthentication no élimine toute cette catégorie d’attaques, ce qui explique sa présence dans toutes les listes de contrôle de hardening. Elle supprime également la solution de secours qui permettait de vous connecter lorsqu’une clé ne fonctionnait plus. Vous devez donc apprendre à distinguer les plusieurs erreurs qui affichent toutes Permission denied (publickey) avant de vous retrouver vous-même bloqué. Ne plus utiliser de mots de passe signifie aussi accumuler des clés. Un agent qui en contient une douzaine les propose l’une après l’autre jusqu’à ce que le serveur atteigne sa limite de tentatives et coupe la connexion. C’est la raison pour laquelle une connexion peut échouer avec Too many authentication failures même lorsque la bonne clé est chargée. La génération et la rotation des clés sont présentées dans les bases de la gestion des clés SSH, et les paramètres côté serveur dans sécuriser 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, et les dates de publication montrent le rythme de ces changements.

Ed25519 est apparu dans OpenSSH 6.5 le 30 janvier 2014, avec le cipher chacha20-poly1305 et un format de clé privée protégé par bcrypt. Les signatures Ed25519 dérivent leur nonce propre à chaque signature de manière déterministe. Un générateur de nombres aléatoires défaillant 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 le chemin 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 au moment de la compilation. La version 10.0, le 9 avril 2025, l’a supprimé, selon les termes du projet, « achevant le processus de dépréciation 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 été retiré. 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 indiquent clairement la raison : SHA-1 est cassé sur le plan cryptographique, et des collisions à préfixe choisi étaient réalisables 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 est en cause. Votre clé est correcte. L’algorithme de signature demandé par l’autre extrémité ne l’est pas.

Le même processus concerne désormais l’échange de clés, cette fois avant que la menace ne devienne concrète. 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és 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 la valeur par défaut : sntrup761x25519-sha512@openssh.com associe un algorithme post-quantique à l’échange X25519. Le résultat n’est donc pas moins sûr que la partie classique si le nouvel algorithme déçoit. OpenSSH 9.9, le 19 septembre 2024, a ajouté mlkem768x25519-sha256, basé sur ML-KEM (mécanisme d’encapsulation de clés à réseau de modules), standardisé par le NIST en 2024. OpenSSH 10.0 en a fait la valeur par défaut pour l’accord de clés, et la page post-quantique du projet explique ce choix. 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 est contrôlé par l’option WarnWeakCrypto dans ssh_config. Ses conséquences pratiques et la marche à suivre pour un serveur qui 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 signifie 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 planifiée, et que chaque suppression a rendu quelque chose incompatible pour certains utilisateurs.

La sécurité de 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 autorisés par sa version et négocie encore vers le bas pour fonctionner avec un client ancien. 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 que personne n’a mise à jour depuis trois ans donne la mesure du problème. Sa vérification fait 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, transmettaient les mots de passe en clair sur le réseau. Toute personne qui surveillait un segment partagé pouvait donc récupérer les identifiants au passage. Il a publié le programme comme freeware en juillet 1995. À la fin de cette même année, il 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 couche de transport, couche d’authentification et couche de connexion (RFC 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 donc confidentiel, même si la clé d’hôte est volée ultérieurement. SSH-1 a été progressivement retiré d’OpenSSH, jusqu’à sa suppression dans la version 7.6 en octobre 2017.

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

Le développement de l’implémentation d’origine a évolué vers un produit commercial avec une licence restrictive. La dernière release librement réutilisable était ssh 1.2.12. Au début de 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 de code audité, distribué sous une licence sans restriction, pour son système de base. Ces deux caractéristiques ont permis à tous les autres systèmes d’exploitation de distribuer la même implémentation par l’intermédiaire de la branche portable.

Pourquoi SSH demande-t-il la clé d’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. SSH identifie donc les serveurs par leur clé et enregistre la clé observée dans ~/.ssh/known_hosts. Lors de la première connexion, aucune valeur enregistrée ne permet d’effectuer cette vérification. Le client vous demande donc de confirmer la clé. Comparez son empreinte avec celle fournie par la console du fournisseur ou par le serveur lui-même. Traitez 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. Lorsque vous vous connectez à un ancien serveur, ce problème se manifeste par sign_and_send_pubkey: no mutual signature supported. Une clé Ed25519, disponible depuis OpenSSH 6.5 en janvier 2014, évite ces deux problèmes.