En quoi SSH est-il différent de Telnet ?

TELNET n’a pas de cryptage, donc tout est transmis en clair. SSH est crypté, il est donc privé et sécurisé. C’est pourquoi SSH doit être utilisé de préférence à TELNET.

SSH et TELNET vous permettent tous deux de vous connecter à des ordinateurs distants en réseau et de les utiliser comme si vous étiez assis devant eux. Alors, quelle est la différence entre ces deux vénérables protocoles, et y a-t-il vraiment toujours un avantage à utiliser SSH sur TELNET ?

TELNET et SSH : l’histoire d’origine

La nécessité est la mère de l’invention. Les administrateurs système avaient besoin d’un moyen d’accéder à des ordinateurs physiquement situés ailleurs et de les gérer. S’il n’était pas pratique ou peu pratique pour l’administrateur de se positionner devant l’ordinateur, il avait besoin d’un moyen d’accéder à l’ordinateur distant lui permettant d’émettre des commandes comme s’il les tapait sur cet ordinateur.

TELNET, abréviation de téletapez dessus filetprotocole de travail, a été développé en 1969 pour répondre à ce problème. Tant que l’ordinateur distant était accessible par le réseau, il permettait à l’administrateur, ou à toute autre personne autorisée, de s’y connecter et de l’utiliser comme s’il appuyait physiquement sur les touches du clavier distant.

SSH a été créé bien plus tard, en 1995, en réponse directe à Telnet et à d’autres solutions similaires. La nécessité cette fois était la sécurité. TELNET, rlogin, FTP et d’autres protocoles de cette époque ont été conçus sans aucune considération ni aucun besoin perçu de sécurité.

SSH signifie ssécurisé sheh bien, vous pouvez donc voir que la sécurité était un principe directeur depuis sa création. De nos jours, SSH a presque entièrement remplacé TELNET.

TELNET est un cauchemar de sécurité en clair

Le gros problème avec TELNET est qu’il utilise du texte en clair. Il ne crypte aucune partie de son trafic, y compris les noms d’utilisateur et les mots de passe. Tout ce qu’il transmet sur le réseau peut être capturé par reniflage de paquets et lu, avec la plus grande facilité. Il s’agit d’un risque de sécurité même sur un réseau local, sauf si vous êtes le seul utilisateur. Tout utilisateur peut intercepter le trafic TELNET et obtenir des identifiants de connexion auxquels il n’a aucun droit.

Si l’ordinateur distant est hors site, nécessitant une connexion à travers Internet pour l’atteindre, le problème est amplifié de manière incommensurable. TELNET était un produit de son temps, et pour être juste envers eux, les auteurs ne s’attendaient certainement pas à ce que les gens l’utilisent bien plus de cinquante ans plus tard, dans le paysage informatique très différent d’aujourd’hui.

Bien que TELNET mérite sa place sur la liste des programmes importants qui nous ont collectivement aidés à nous rendre là où nous en sommes aujourd’hui, ce n’est pas quelque chose que nous devrions encore utiliser dans le monde d’aujourd’hui.

En quoi SSH est-il différent de TELNET ?

À première vue, TELNET et SSH sont deux réponses au même problème. Ils vous permettent tous les deux d’accéder à une fenêtre de terminal sur un ordinateur distant et de lui envoyer des commandes. Mais parce que SSH a été développé beaucoup plus tard que TELNET, le problème a été mieux compris et la réponse a été mieux conçue.

TELNET a été conçu avec privé réseaux à l’esprit, mais SSH a été conçu pour faire face à public réseaux, et la nécessité de maintenir la confidentialité et la sécurité lors du transfert de données et de l’établissement de connexions à distance.

TELNET utilise le port 23 et ce numéro de port ne peut pas être modifié. Par défaut, SSH utilise le port 22, mais cela peut être configuré et modifié. La configuration de SSH pour utiliser un numéro de port non évident rend plus difficile pour les attaquants d’identifier le port SSH. Si le port SSH peut être identifié, il est facile de monter une attaque par force brute où des milliers de mots de passe récoltés à partir de violations de données sont essayés à leur tour, par un logiciel automatisé.

Mieux encore, SSH peut se passer complètement de mots de passe. Il peut utiliser le chiffrement à clé publique pour s’authentifier auprès d’ordinateurs distants. Les mots de passe ne sont jamais transmis du tout, car il n’est pas nécessaire de les envoyer à l’ordinateur distant. Son cryptage des données et son authentification par clé SSH signifient que SSH est capable de fournir des connexions et des communications sécurisées sur des réseaux non sécurisés comme Internet.

En fait, SSH peut être utilisé pour s’authentifier auprès de différents services, pas seulement des ordinateurs distants exécutant un serveur SSH. Par exemple, vous pouvez accéder aux référentiels Git hébergés sur GitHub, GitLab et BitBucket à l’aide de SSH au lieu de mots de passe.

Un autre avantage de l’utilisation de SSH sur TELNET est que SSH peut effectuer un tunnel SSH inversé. Cela nécessite que le serveur établisse une connexion avec l’ordinateur client. Tant que l’utilisateur local ne souhaite pas se connecter au serveur, la connexion est ignorée.

Lorsque le client veut se connecter au serveur, l’utilisateur établit une connexion SSH avec son propre ordinateur. SSH envoie la connexion via la connexion déjà établie, au serveur. Cela fournit un tunnel privé à l’intérieur de la connexion déjà cryptée du serveur au client.

Le seul avantage de TELNET est qu’il utilise moins de bande passante. Mais ce n’est pas 1969 où la bande passante était rare, et SSH n’est pas non plus exactement un porc de bande passante.

SSH a aussi eu ses problèmes

Bien que SSH surpasse TELNET en matière de sécurité, nous devons nous rappeler qu’il s’agit toujours d’un logiciel et que le logiciel peut avoir des bogues. Ces bugs peuvent conduire à des vulnérabilités qui peuvent être exploitées par des cybercriminels. De plus, les normes de chiffrement et les algorithmes changent avec le temps et sont remplacés. Comme tous les logiciels basés sur le cryptage, à mesure que les anciennes versions de SSH vieillissent, ils peuvent devenir moins sécurisés. C’est pourquoi il est important de s’assurer que vous utilisez la dernière version de SSH.

La version de SSH utilisée dans la plupart des ordinateurs Linux est OpenSSH, une implémentation de SSH qui s’appuie sur la boîte à outils et les bibliothèques OpenSSL. En 2012, la bibliothèque OpenSSL a accidentellement introduit un bogue qui permettait à un attaquant de demander une réponse au serveur SSL et de spécifier la quantité de données à contenir dans la réponse.

Ils pourraient demander une réponse de (disons) 64 Ko alors que la réponse réelle n’aurait pas nécessité plus de 64 octets. La première séquence d’octets dans ces données serait la véritable réponse attendue, suivie de tout ce qui se trouverait dans la mémoire récemment utilisée par OpenSSL. Ce que contenaient ces données était de la chance, mais elles pouvaient contenir des informations sensibles telles que des cookies de session et des mots de passe, ou d’autres informations permettant à un attaquant d’acquérir des clés privées, par exemple.

Une fois découverte, en 2014, la vulnérabilité est devenue connue sous le nom de Heartbleed. Cela a été rapidement corrigé dans le logiciel. Cependant, la vulnérabilité ne disparaît pas à ce stade. La vulnérabilité n’est complètement annulée que lorsque la version corrigée est installée sur tous les ordinateurs exécutant le logiciel vulnérable. En d’autres termes, lorsque les ordinateurs ont été patché. Étant donné que de nombreux administrateurs ont été lents à réagir, l’adoption du logiciel corrigé a été lente.

Les deux années entre 2012, date à laquelle le bogue a été introduit et 2014, date à laquelle il a été découvert et corrigé, sont également inquiétantes. Pendant ces deux années, chaque serveur SSH exécutant la version vulnérable d’OpenSSL était à risque.

Pour être juste, cela s’est produit il y a pratiquement une décennie, et depuis lors, il y a eu de nombreuses versions, améliorations, corrections de bogues et révisions de code.

Devriez-vous utiliser SSH ou TELNET ?

Il est difficile de penser à une raison pour laquelle vous auriez besoin d’utiliser TELNET aujourd’hui. Ce n’est pas la même chose que de dire s’il existe un scénario dans lequel il est sûr d’utiliser TELNET. Dans un réseau autonome qui n’est pas connecté au monde extérieur, et vous êtes sûr que personne ne va renifler votre trafic, vous pouvez utiliser TELNET. Mais il n’y a aucune raison de le faire. Le compromis de sécurité ne peut pas être justifié.

SSH est plus sécurisé et plus flexible, c’est l’avantage d’utiliser SSH sur TELNET. L’implémentation OpenSSH est gratuite pour toutes les utilisations, y compris commerciales, et est disponible pour tous les systèmes d’exploitation courants.