Qu’est-ce que SSH et comment ça marche ?

S sécurisé Ch ell (SSH) est un protocole de sécurité couramment implémenté avec une gamme d'utilisations différentes. Son application la plus connue permet aux utilisateurs deaccéder en toute sécurité aux ordinateurs et serveurs distants, mais il peut également être utilisé pour le tunneling, la redirection de port, les transferts de fichiers sécurisés et bien plus encore.

Dans ce guide, nous couvrironsqu'est-ce que SSH, à quoi il sert, l'historique du protocole, ses détails techniques, aussi bien queles problèmes de sécuritéqu'il faut prendre en considération.

SSH est composé de trois protocoles distincts :la couche transport, la couche d'authentification et la couche connexion. Ensemble, ceux-ci servent à authentifier l’autre partie dans la connexion, à assurer la confidentialité grâce au cryptage et à vérifier l’intégrité des données. SSH est désormais le plus souvent implémenté soit sous la forme propriétaire SSH-2, soit sous la forme d'une itération open source, OpenSSH.

Les utilisations de SSH

SSH est un protocole polyvalent. Sa structure et ses fonctionnalités de sécurité lui permettent d'être utilisé de plusieurs manières, notamment pour l'accès à distance, la redirection de port, le tunneling et les transferts de fichiers sécurisés.

Accès à distance

L'accès à distance permet aux utilisateurs dese connecter à un autre ordinateur ou serveur à partir de sa propre machine. Il est utilisé pour accéder aux fichiers locaux de la machine cible ou y effectuer des services, le tout sans avoir à y être physiquement.

Des programmes comme Telnet et rlogin disposent également de cette fonctionnalité, mais ils ne disposent pas des fonctionnalités de sécurité de SSH. Les mesures de cryptage et d'authentification impliquées dans SSH permettent aux utilisateurs de se connecter à un autre serveur ou ordinateur de manière protégée, même via un réseau intermédiaire potentiellement dangereux.

L'accès à distance avec SSH est couramment mis en œuvre pour que les employés puissent travailler à distance ou pour permettre au service informatique d'accomplir des tâches sans avoir à se rendre physiquement à la machine. Il peut être utilisé pour l'administration à distance, la gestion de l'infrastructure réseau, pour configurer l'automatisation, créer des sauvegardes et bien plus encore.

Redirection de port

Redirection de port est utilisé pour transférer les demandes d’une adresse et d’un numéro de port vers un autre ensemble. Il applique la traduction d'adresses réseau (NAT) pour rediriger les ports entre un réseau local et un ordinateur distant, vous permettant ainsi d'accéder à un périphérique depuis l'extérieur du réseau.

La redirection de port peut être effectuée de trois manières différentes :

• Locale redirection de port – La redirection de port local vous permet de connecter votre client local et un réseau externe. Cela peut être efficace pour accéder à des sites Web bloqués localement ou pour se connecter à une base de données située derrière un pare-feu.
• Redirection de port distant – Ce type de transfert permet aux applications côté serveur d'accéder aux services côté client. La redirection de port distant de SSH permet aux utilisateurs de se connecter en toute sécurité à des serveurs distants via leur PC local en redirigeant un port local vers un serveur SSH distant.
• Dynamique redirection de port – Cela permet aux utilisateurs d'envoyer leurs données via un port particulier vers un ordinateur ou un serveur distant en utilisant un certain nombre de serveurs SSH agissant comme proxy.

Tunneling

Les protocoles de tunneling utilisent l'encapsulation pour déplacer les données entre les réseaux. Des tunnels peuvent être déployés pour permettre à des protocoles non natifs de fonctionner sur des réseaux qui ne les prendraient normalement pas en charge. Une autre utilisation courante est pourassurer la sécurité sur un réseau dangereux.

Les protocoles de tunneling enveloppent les paquets critiques dans la charge utile d'un autre paquet. Le tunneling SSH permet aux utilisateurs de contourner la sécurité du réseau, de relier des appareils à l'aide d'un protocole réseau non natif et de sécuriser les données transmises. Ils sont fréquemment utilisés pour connecter des utilisateurs distants aux ressources en ligne de leur organisation de manière sécurisée.

SFTP

Le protocole FTP (SSH File Transfer Protocol), parfois appelé Secure File Transfer Protocol, offre un moyen sûr d'accéder, de transférer et de gérer des fichiers. Il s'agit d'une alternative sécurisée au FTP et exploite le protocole SSH pour envoyer, recevoir et administrer des fichiers en toute sécurité.

SCP

Le Secure Copy Protocol (SCP) est similaire au SFTP, mais sa portée est plus limitée. Il permet uniquement les transferts de fichiers sécurisés, plutôt que l'ensemble complet des fonctionnalités permettant SFTP pour agir comme un protocole de système de fichiers distant.

Plateformes et applications utilisant SSH

SSH ou OpenSSH propriétaire peut être utilisé sur tous les principaux systèmes d'exploitation. Il est disponible sur les plates-formes Unix comme OpenBSD, macOS, Linux et Solaris, tandis que les utilisateurs Windows peuvent utiliser SSH à travers PowerShell .

L'histoire de SSH

SSH a été développé à l’Université de technologie d’Helsinki en 1995 par Tatu Ylönen en réponse à une attaque par détection de mots de passe sur le réseau de l’université. Il visait à fournir une alternative aux protocoles comme FTP, TELNET, rsh et connexion , qui ne garantissait pas la confidentialité ni authentifiait les utilisateurs de manière sécurisée.

SSH a été rendu public gratuitement en 1995 et a été bien accueilli. Au milieu de son adoption rapide, Ylönen a fondé SSH Communications Security à la fin de la même année afin de poursuivre le développement et de commercialiser SSH.

En 1995, Ylönen a également publié un projet Internet de l'Internet Engineering Task Force (IETF) quia documenté le protocole SSH-1. Des limitations ont rapidement été découvertes dans le protocole, et celles-ci n’ont pas pu être résolues sans affecter la compatibilité ascendante. La solution était une nouvelle version du protocole et SSH-2 a été lancé par la société Ylönen en 1996.

SSH-2 présentait de nouveaux algorithmes, ce qui a incité l'IETF à fonder un groupe de travail visant à normaliser le protocole. Le groupe était surnommé SECSH, pour Seconde ure Ch ell, et il a publié son premier brouillon Internet pour SSH-2 en 1997.

Le logiciel pour SSH-2 était sorti en 1998 , mais il n’a pas été immédiatement adopté de manière généralisée en raison de ses licences plus restrictives.En 2006, une version modifiée du protocole est devenue une norme par l'IETF.. C'était plus sécurisé, utilisant des codes d'authentification de message pour vérifier l'intégrité et l'échange de clés Diffie-Hellman pour l'authentification.

En 1999, le projet OpenBSD a publié OuvertSSH .OpenSSH est une version gratuite du protocolequi est basé sur les modifications apportées par Björn Grönvall à SSH 1.1.12. Les développeurs sont revenus à cette ancienne version et l'ont fortement modifiée, car c'était la dernière version de SSH entièrement open source. OpenSSH est désormais l'option la plus largement utilisée et a depuis été implémentée dans une gamme de systèmes d'exploitation, tels que Windows, macOS, Linux, Solaris et autres.

SSH-1 contre SSH-2 contre OpenSSH

Comme indiqué ci-dessus, SSH-1 est la première version du protocole, initialement publiée sous unlicence open source. Il est considéré comme non sécurisé et ne devrait pas être mis en œuvre. Cela laisse la version propriétaire, SSH-2, et la version disponible gratuitement, OpenSSH, comme alternatives viables.

SSH-2 et OpenSSH sont essentiellement les mêmes en ce qui concerne leur architecture et leur fonctionnement. La principale différence est que la version propriétaire est livrée avec une gamme d'options de support, tandis que ceux qui utilisent OpenSSH doivent s'appuyer sur les ressources créées librement par la communauté.

SSH : Les détails techniques

SSH-1 fonctionnait comme un protocole unique, mais nous n’y reviendrons pas ici car il est obsolète. Au lieu de cela, nous nous concentrerons sur SSH-2 et OpenSSH, qui sont tous deux constitués de trois protocoles distincts :

• Le protocole de transport – Cela établit la connexion et fournit la sécurité sous-jacente.
• Le protocole d'authentification – Cette couche est utilisée pour authentifier le client.
• Le protocole de connexion – Ce protocole gère les canaux sur lesquels les données sont transmises.

Chacun de ces protocoles joue un rôle unique qui vise à établir et sécuriser une connexion, à authentifier l'autre partie et à transférer des données. Le port de connexion TCP par défaut est 22 et les connexions sont établies entre un client SSH et un serveur SSH le long du port.modèle client-serveur.

Le processus de connexion à distance de SSH se déroule selon la structure de base suivante (avec des variations en fonction de la configuration), que nous aborderons plus en détail ultérieurement :

• Le client contacte le serveur SSH pour établir la connexion.
• Le serveur envoie ensuite sa clé publique au client pour authentifier son identité.
• Les deux parties négocient les paramètres de connexion, puis établissent un canal sécurisé le long de ces lignes.
• L'utilisateur se connecte ensuite au système d'exploitation de l'hôte du serveur et peut désormais administrer ses tâches à distance.

Protocole de transport

La couche transport est un protocole de bas niveau qui prend en charge les tâches suivantes.

• Authentification de l'hôte du serveur
• Échange de clés
• Chiffrement pour la confidentialité des données
• Contrôles d'intégrité pour vérifier que les données n'ont pas été altérées
• Établir un identifiant de session pouvant être utilisé dans les autres protocoles

Lele protocole de transport authentifie uniquement le serveur et non le client(l'authentification du client se fait dans le protocole d'authentification si elle est requise).

Dans la couche transport, la connexion est initiée par le client et les deux parties négocient ensuite comment les clés seront échangées, quel algorithme à clé publique sera utilisé, quel chiffre à clé symétrique chiffrera les données, quel algorithme d'authentification des messages sera utilisé. pour vérifier les données et quelle méthode de compression (le cas échéant) sera implémentée.

Une fois la connexion établie, le serveur et le client doivent envoyer une chaîne d'identification, qui inclut la version du protocole (2.0).

Négociation d'algorithme

Pour configurer les paramètres de connexion, les deux côtés envoient un paquet contenant une liste avec les options suivantes :

octet SSH_MSG_KEXINIT

cookie byte[16] (octets aléatoires)
liste de noms kex_algorithms
liste de noms server_host_key_algorithms
liste de noms chiffrement_algorithms_client_to_server
liste de noms chiffrement_algorithms_server_to_client
liste de noms mac_algorithms_client_to_server
liste de noms mac_algorithms_server_to_client
liste de noms compression_algorithms_client_to_server
liste de noms compression_algorithms_server_to_client
liste de noms langues_client_to_server
liste de noms langues_serveur_vers_client
booléen first_kex_packet_follows
uint32 0 (réservé pour une extension future)

Chaque côté répertorie les paramètres qu'il est prêt à accepter dans la connexion, séparés par des virgules. L'algorithme préféré doit être répertorié en premier.

Pour échange de clés (kex_algorithms), le premier algorithme pris en charge par les deux parties sera choisi pour la connexion (il peut également y avoir d'autres facteurs à respecter, en fonction de l'algorithme qui a été choisi). Si les deux parties ne parviennent pas à trouver un algorithme mutuellement pris en charge qui satisfait à ces exigences, la connexion échoue.

Algorithmes de clé d'hôte du serveur sont les algorithmes pris en charge pour la clé d'hôte du serveur. Le serveur présente les algorithmes pour lesquels il dispose de clés d'hôte, tandis que le client spécifie les algorithmes qu'il est prêt à accepter. La sélection dépendra de la question de savoir si la méthode d'échange de clé choisie nécessite une clé hôte capable de chiffrer ou une signature numérique.

Les deux côtés énumèrent algorithmes à clé symétrique qu'ils sont prêts à accepter, avec les méthodes préférées en tête. La première option qui apparaît sur la liste des clients et qui se trouve également sur la liste des serveurs doit être utilisée. Si aucun accord ne peut être trouvé, la connexion échoue.

Les deux Algorithme MAC et le algorithme de compression sont négociés de la même manière.

Échange de clés

L'échange de clés est responsable deauthentification du serveur, et celaconfigure les clés qui serviront à sécuriser la connexiondans les étapes suivantes. Cela commence généralement par l’envoi mutuel par les parties de leurs listes d’algorithmes pris en charge. Alternativement, chaque côté peut deviner l’algorithme préféré de l’autre côté et envoyer au départ un paquet qui correspond aux paramètres de cet algorithme.

Si l’hypothèse d’une partie est correcte, ce paquet est utilisé comme premier paquet d’échange de clés. Si aucune des hypothèses n’est exacte, chaque partie doit prendre du recul et envoyer sa liste d’algorithmes préférés. Si le message d’échange de clé inclut la signature numérique du serveur comme preuve de la légitimité du serveur, il est considéré authentification explicite du serveur . S'il utilise le secret partagé à la place, il est appelé authentification implicite du serveur .

L'échange de clés est également chargé d'établir un secret partagé et un hachage. La valeur de hachage issue de l'échange initial de clé devient l'identifiant unique de la session et est également utilisée dans le cadre des signatures numériques qui prouvent que la partie est le véritable propriétaire de sa clé privée.

La fonction de hachage utilisée dépendra de la méthode d'échange de clé décidée lors de la négociation. Une fois l’échange de clés terminé, toutes les communications futures utiliseront le nouvel ensemble de clés et d’algorithmes.

Selon un groupe de travail sur l'ingénierie Internet (IETF) Brouillon Internet , les méthodes d'échange de clés suivantes sont considérées comme sécurisées :

• courbe25519-sha256
• courbe448-sha512
• diffie-hellman-group-exchange-sha256
• diffie-hellman-group14-sha256
• diffie-hellman-group15-sha512
• diffie-hellman-group16-sha512
• diffie-hellman-group17-sha512
• diffie-hellman-group18-sha512
• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• gss-groupe14-sha256
• gss-groupe15-sha512
• gss-groupe16-sha512
• gss-groupe17-sha512
• gss-groupe18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-courbe25519-sha256
• gss-courbe448-sha512
• rsa2048-sha256

Algorithme de clé d'hôte du serveur

Ces algorithmes à clé publique sont utilisés pourl'authentification du serveur ainsi que pour établir en toute sécurité l'ID de session partagée. Ils peuvent également être éventuellement utilisés pour authentifier l’hôte. SSH est conçu pour fonctionner avec une gamme d’algorithmes à clé publique, de types et de formats d’encodage :

• Il utilise des algorithmes à clé publique pour le cryptage et/ou les signatures numériques.
• Une gamme de méthodes de codage peut être implémentée, permettant une configuration avec différents formats de données, remplissage et ordre des octets.
• Différents formats de clés permettent de coder les clés de différentes manières, ainsi qu'une gamme de représentations de certificat.

Les algorithmes par défaut incluent les éléments suivants, mais il existe d'autres variantes qui peuvent également être implémentées :

• ssh-rsa
• ssh-rsa-sha256
• ssh-dss
• ssh-dss-sha256
• x509v3-sign-dss
• x509v3-sign-dss-sha256
• x509v3-sign-rsa
• x509v3-sign-rsa-sha256

Algorithmes de chiffrement

Des algorithmes à clé symétrique sont utilisés pourcrypter les données et assurer la confidentialité.Les paramètres et la clé partagée utilisés dans le processus de cryptage sont établis lors des phases antérieures de la connexion. L'algorithme choisi chiffre la charge utile, la longueur du paquet, la longueur du remplissage et les champs de remplissage.

Une gamme d'algorithmes de chiffrement différents sont acceptés dans SSH, mais pour des raisons de sécurité, il est préférable de s'en tenir à AES . Les clés doivent avoir au minimum 128 bits, mais des clés plus grandes sont préférables.

Algorithmes MAC

Le protocole de transportvérifie l'intégrité des données en ajoutant un code d'authentification de message (MAC) au paquet.Ce MAC est basé sur le secret partagé (qui est établi lors de l'échange de clés), le numéro de séquence du paquet et le contenu du paquet. Il est calculé avant le cryptage.

Les implémentations doivent offrir un algorithme indépendant pour s'exécuter dans chaque direction, même s'il est idéal si le même est utilisé des deux côtés. Une grande variété d'algorithmes d'authentification de message peuvent être implémentés, mais SHA-256 et supérieur doivent être utilisés dans la plupart des situations pour garantir un niveau élevé de sécurité.

Compression

La compression n'est pas obligatoire dans le protocole SSH et ses implémentations doivent permettre aux connexions de se dérouler sans compression. La compression ne peut être mise en œuvre qu'en option, en utilisant des schémas tels que zlib . Si la compression est utilisée, elle affecte uniquement la charge utile. Le MAC et le champ de longueur du paquet sont ensuite calculés sur la base de la charge utile compressée.

Paquet de protocole de transport

Le paquet de protocole de transport est formaté pour inclure les informations suivantes (ainsi que certains détails moins pertinents qui ont été omis) :

• La longueur du paquet
• La longueur du rembourrage
• La charge utile
• Rembourrage
• Un code d'authentification de message (MAC)

Protocole d'authentification

Ce protocole est utilisé par le serveur pourauthentifier le client.Il peut le faire à l'aide de différents mécanismes, dont beaucoup s'appuient sur l'ID de session établi dans le protocole de transport. Certains utilisent les contrôles de chiffrement et d'intégrité du protocole de transport en conjonction avec l'ID de session, tandis que d'autres utilisent ces algorithmes eux-mêmes.

Le serveur utilise sa politique locale pour décider quelles méthodes d'authentification il accepte d'un utilisateur individuel. Le serveur étant déjà authentifié dans le protocole de transport,il n'est pas nécessaire d'authentifier à nouveau le serveur.

La sécurité du protocole d'authentification dépend du protocole de transport sur lequel il s'exécute. Si le protocole de transport ne peut pas garantir la confidentialité ou vérifier l'intégrité des données, cela limite la manière dont le protocole d'authentification peut être utilisé en toute sécurité.

Par exemple, si la protection de l’intégrité n’est pas appliquée par le protocole de transport, les demandes telles que les changements de mot de passe ne devraient pas être autorisées, car cela laisserait aux attaquants la possibilité de falsifier les données sans se faire remarquer.

Le protocole d'authentification utilise l'authentification par clé publique en supposant que ni la clé privée de l'hôte serveur, ni la clé de l'hôte client n'ont été compromises.Si le serveur a été compromis, cela peut conduire à ce que le nom d'utilisateur et le mot de passe du client soient divulgués à l'attaquant..

Pour que l'authentification basée sur l'hôte soit sécurisée, le client ne doit pas être compromis. Si cela est possible, d'autres méthodes d'authentification doivent être ajoutées. Il est important de noter que le processus d'authentification est aussi puissant que la méthode d'échange la plus faible acceptée par un serveur.

Le processus du protocole d'authentification

Le protocole d'authentification commence lorsque le serveur envoie au client une liste de ses méthodes d'authentification acceptées. Le client peut alors choisir parmi ces méthodes dans n'importe quel ordre. Ce processus donne le contrôle au serveur, mais permet également suffisamment de flexibilité pour que le client puisse s'arranger pour utiliser la méthode la plus pratique.

Les méthodes d'authentification client les plus courantes incluent :

• Clé publique – Cette méthode utilise des algorithmes tels que RSA , DSA et ECDSA pour authentifier le client via la cryptographie à clé publique. Certaines implémentations utilisent également des certificats x.509. Le serveur vérifie la signature numérique du client par rapport à sa clé publique pour vérifier l’identité du client.
• Mot de passe – Les mots de passe peuvent également être utilisés pour authentifier le client. Le client envoie son mot de passe (qui doit être crypté par le protocole de transport). Si le mot de passe correspond à la valeur stockée sur le serveur, il est accepté et l'authentification continue.
• GSSAPI – Avec cette méthode, des schémas externes tels que Kerberos peuvent être utilisés pour l'authentification unique.
• Clavier interactif – Cette technique fournit une authentification par mot de passe à usage unique en demandant au serveur de demander des informations au client.

Protocole de connexion

Le protocole de connexion définitcomment plusieurs canaux de données seront combinés sur la couche de transport sécurisée. Il traite également des paramètres utilisés pour accéder aux sous-systèmes sécurisés sur l'hôte du serveur, ainsi que du transfert de proxy et de l'accès aux shells.

Le protocole de connexion se situe au-dessus de la couche de transport et des protocoles d'authentification. Il permet l'exécution de commandes à distance, ainsi que les connexions X11 et TCP/IP transférées. Si le serveur ou le client a été compromis, le protocole de connexion n'est pas sécurisé.

Canaux

Les canaux constituent les voies de communication de base et peuvent être ouverts par l’une ou l’autre des parties. Les canaux peuvent inclure des sessions de terminal, des connexions transférées et d'autres formes de communication. Lorsqu'il existe plusieurs canaux, ils sont multiplexés en une seule connexion.

Chaînes d'ouverture

Chaque canal est numéroté à ses deux extrémités, bien que les numéros puissent potentiellement être différents de chaque côté. Lorsqu'une partie demande l'ouverture d'un canal, elle envoie son numéro de canal dans le cadre du message, ainsi que des informations sur le canal. taille initiale de la fenêtre et le taille maximale du paquet .

La taille initiale de la fenêtre indique la quantité de données que la partie qui ouvre le canal peut recevoir. Si davantage de données doivent être envoyées, la fenêtre doit d’abord être ajustée. De même, la taille maximale du paquet spécifie la taille d'un paquet qui peut être reçu.

Lorsqu’un côté demande l’ouverture d’un canal, l’autre côté ouvrira le canal s’il peut l’accepter. Sinon, il enverra un message d'échec. Les canaux peuvent ne pas s'ouvrir pour les raisons suivantes :

• Interdit par l'administration
• Échec de la connexion
• Type de canal inconnu
• Pénurie de ressources

Si l'un des côtés de la connexion souhaite envoyer plus de données que la fenêtre ne le permet actuellement, il peut envoyer un message demandant d'ajouter plus d'octets.

Fermeture des chaînes

Une fois qu'un côté d'une connexion a terminé sa transmission de données, il doit envoyer un message indiquant qu'il a fini d'utiliser le canal. Malgré cela, le canal reste ouvert et les données peuvent toujours être envoyées par l’autre partie. Si une partie souhaite mettre fin complètement au canal, elle le fait avec un message de terminaison distinct.

Sécurité SSH

Les différentes versions de SSH ont chacune leurs propres problèmes de sécurité, bien que les configurations actuelles deSSH-2 et OpenSSH sont considérés comme beaucoup plus sûrs que SSH-1.

SSH-1

SSH-1 est généralement considéré comme défectueux, avec une série de vulnérabilités différentes. Il s'agit notamment d'un bug dans SSH 1.5 qui permettait à des utilisateurs non autorisés d'insérer du contenu dans le flux de données SSH. Cette attaque a profité de la protection minimale de l’intégrité des données de l’algorithme CRC-32.

Cette attaque a été atténuée grâce au détecteur d'attaque de compensation SSH, qui a été intégré dans la plupart des implémentations les plus récentes. Ce correctif était accompagné d'une nouvelle vulnérabilité, qui avait le pouvoir d'exécuter du code arbitraire avec les privilèges root.

Il existe également une vulnérabilité qui permet aux adversaires de modifier le dernier bloc d'une session utilisant le cryptage IDEA, ainsi qu'une autre qui permet à un serveur compromis de transmettre le processus d'authentification du client à un autre serveur.

En raison de ces problèmes de sécurité, SSH-2 doit être utilisé à la place. Pour assurer la sécurité de votre implémentation, vous devez également désactiver la renégociation vers SSH-1 , car les attaques peuvent en profiter pour accéder à vos données via le niveau de protection plus faible de SSH-1.

SSH-2

SSH-2 est vulnérable à une attaque théorique contre son mode de chiffrement par défaut, CBC. Il permet à l'attaquant de récupérer jusqu'à 32 bits du texte brut d'un bloc chiffré. Cela peut être atténué en utilisant le mode Compteur (CTR) et en transformant le chiffrement par bloc en chiffrement de flux.

Fin 2014, Le miroir a publié des documents de la NSA qui impliquaient que la NSA pouvait parfois casser SSH. Un PowerPoint de la NSA divulgué a déclaré que la NSA peut «Récupérer potentiellement les noms d'utilisateur et les mots de passe», même si aucun autre détail n’est donné. On ne sait pas quelles méthodes l’agence a utilisées pour y parvenir, mais il semble peu probable qu’elle mente sur ses capacités dans sa propre documentation interne.

En 2017 Fuite du coffre-fort 7 , il a été révélé quela CIA disposait de deux outils qui pouvaient être utilisés pour intercepter et voler les identifiants et mots de passe SSH. BothanSpy ciblait les clients Windows Xshell, tandis que Gyrfalcon était utilisé contre le client OpenSSH sur un certain nombre de distributions Linux différentes.

Ces outils sont capables de voler des informations d'identification puis de les retransmettre à un serveur de la CIA. Aucune de ces attaques ne peut briser le protocole lui-même ; ils utilisent simplement d'autres attaques par canal secondaire qui peuvent le contourner dans certaines implémentations.

Malgré ces attaques, SSH-2 est considéré comme sécurisé dans la plupart des situations, à condition qu'il soit implémenté de manière appropriée. Les cibles de grande valeur ou celles qui utilisent des implémentations obsolètes ou médiocres devraient envisager d’autres options.

OuvertSSH

Dans OpenSSH version 2,un attaque a été découvert qui a profité d'une faiblesse dans le paquet binaire SSH. L'attaque a permis à des chercheurs de l'Université de Londres de récupérer 14 bits du texte brut d'un bloc crypté. Ce problème a été atténué dans la version 5.2 en obligeant le protocole à lire l'intégralité d'une longueur de paquet ou d'un code d'authentification de message non valide, plutôt que de mettre fin à la connexion.

Dans les versions 6.8 et 6.9, Linux pouvait être utilisé pour exécuter des commandes arbitraires sur les terminaux d'autres utilisateurs. Cela a été réalisé grâce à une vulnérabilité d'élévation de privilèges qui permettait aux attaquants d'injecter des caractères avec le contrôle d'entrée/sortie TIOCSTI.

SSH est-il sûr ?

Bien qu'il puisse sembler que SSH présente de nombreux problèmes de sécurité,c'est relatifIl est normal qu’un certain nombre de vulnérabilités soient trouvées dans les différentes implémentations d’un protocole. Cela ne signifie pas que le protocole SSH n'est pas sécurisé. Au lieu de cela, cela signifie simplement queil doit être mis en œuvre correctement.

Tant que vous utilisez soitSSH-2 ou OpenSSH et qu'il est configuré d'une manière adaptée à votre utilisation, vous devez avoir confiance dans la protection que SSH offre à votre connexion.. C’est pourquoi il s’agit toujours d’un protocole si fréquemment utilisé, notamment à des fins d’accès à distance et de tunneling.

Voir également: Types de cryptage courants expliqués

Contexte de la technologie des cyber-réseaux par TheDigitalArtist sous licence CC0