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

Sécure Shell (SSH) est un protocole de sécurité couramment implémenté avec une gamme d’utilisations différentes. Son application la plus renommée permet aux utilisateurs de accé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 plus encore.

Dans ce guide, nous allons couvrir ce qu’est SSH, à quoi il sert, l’historique du protocole, ses détails techniques, aussi bien que les problèmes de sécurité qui doivent être pris en considération.

SSH est composé de trois protocoles distincts: la couche transport, la couche authentification et la couche connexion. Ensemble, ceux-ci servent à authentifier l’autre partie dans la connexion, à assurer la confidentialité grâce au chiffrement et à vérifier l’intégrité des données. SSH est maintenant le plus souvent implémenté en tant que SSH-2 propriétaire, ou en tant qu’itération open-source, OpenSSH.

Les utilisations de SSH

SSH est un protocole polyvalent. Sa structure et ses fonctions de sécurité lui permettent d’être utilisé de plusieurs façons, comme 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 de se 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, sans avoir à être physiquement présent.

Des programmes comme Telnet et rlogin ont également cette fonctionnalité, mais ils n’ont pas les fonctionnalités de sécurité de SSH. Les mesures de chiffrement 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 sur un réseau intermédiaire potentiellement dangereux.

L’accès à distance avec SSH est généralement mis en œuvre afin que les employés puissent travailler à distance ou pour permettre au service informatique d’accomplir des tâches sans avoir à se rendre physiquement sur 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, etc..

Transfert de port

La redirection de port est utilisée pour transférer des demandes d’une adresse et d’un numéro de port à 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 d’accéder à un périphérique depuis l’extérieur du réseau.

La redirection de port peut se faire de trois manières différentes:

• Local redirection de port – La redirection de port local vous permet de connecter votre client local et un réseau externe. Il 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 à distance – Ce type de transfert permet aux applications côté serveur d’accéder aux services côté client. La redirection de port à distance 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 à un ordinateur ou un serveur distant en utilisant un certain nombre de serveurs SSH qui agissent comme des proxys.

Tunneling

Les protocoles de tunneling utilisent l’encapsulation pour déplacer les données entre les réseaux. Les tunnels peuvent être déployés pour permettre aux protocoles non natifs de s’exécuter sur des réseaux qui ne les prennent normalement pas en charge. Une autre utilisation courante est assurer la sécurité sur un réseau dangereux.

Les protocoles de tunnellisation enveloppent les paquets critiques à l’intérieur de la charge utile d’un autre paquet. La tunnellisation SSH permet aux utilisateurs de contourner la sécurité du réseau, de lier 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 les utilisateurs distants aux ressources en ligne de leur organisation de manière sécurisée.

SFTP

Le protocole SSH File Transfer Protocol (FTP), parfois appelé Secure File Transfer Protocol, fournit 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 tire parti du protocole SSH pour envoyer, recevoir et administrer des fichiers en toute sécurité.

SCP

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

Plateformes & les applications qui utilisent SSH

SSH ou OpenSSH propriétaires peuvent être utilisés sur tous les principaux systèmes d’exploitation. Il est disponible sur les plateformes basées sur Unix comme OpenBSD, macOS, Linux et Solaris, tandis que les utilisateurs Windows peuvent utiliser SSH via 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 reniflement de mot de passe sur le réseau de l’université. Il visait à fournir une alternative aux protocoles comme FTP, TELNET, rsh et rlogin, qui n’a pas assuré la confidentialité ou authentifié 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 d’ici la fin de la même année afin de poursuivre le développement et la commercialisation de SSH.

En 1995, Ylönen a également publié un projet Internet de l’IETF (Internet Engineering Task Force) documenté le protocole SSH-1. Des limitations ont rapidement été trouvées dans le protocole, et elles ne pouvaient pas être résolues sans affecter la compatibilité descendante. La solution était une nouvelle version du protocole, et SSH-2 a été lancé par la société Ylönen en 1996.

SSH-2 comportait de nouveaux algorithmes, ce qui a incité l’IETF à fonder un groupe de travail visant à normaliser le protocole. Le groupe a été surnommé SECSH, car Secondeure Shell, et il a publié son premier projet Internet pour SSH-2 en 1997.

Le logiciel pour SSH-2 est sorti en 1998, mais il n’a pas été immédiatement adopté de manière généralisée en raison de sa licence plus restrictive. En 2006, une version modifiée du protocole est devenue une norme par l’IETF. C’était plus sûr, en 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é OpenSSH. OpenSSH est une version gratuite du protocole qui 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 profondément modifiée, car c’était la dernière version de SSH qui était complètement open source. OpenSSH est désormais l’option la plus utilisée et elle a depuis été mise en œuvre 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, qui a été initialement publié sous un licence open source. Il est considéré comme non sécurisé et ne doit 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 entrerons 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 – Ceci é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 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 plus loin:

• Le client contacte le serveur SSH pour commencer la connexion.
• Le serveur envoie ensuite sa clé publique au client pour authentifier son identité.
• Les deux parties négocient les paramètres de la 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 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
• Cryptage pour la confidentialité des données
• Contrôles d’intégrité pour vérifier que les données n’ont pas été modifiées
• Établir un identifiant de session qui peut être utilisé dans les autres protocoles

le le protocole de transport authentifie uniquement le serveur et non le client (l’authentification client se fait dans le protocole d’authentification si nécessaire).

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 de clé publique sera utilisé, quel chiffrement à clé symétrique cryptera les données, quel algorithme d’authentification de message 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’algorithmes

Pour configurer les paramètres de la connexion, les deux parties envoient via un paquet contenant une liste avec les options suivantes:

octet SSH_MSG_KEXINIT

octet [16] cookie (octets aléatoires)
liste de noms kex_algorithms
liste de noms server_host_key_algorithms
liste de noms encryption_algorithms_client_to_server
liste de noms encryption_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 languages_client_to_server
liste de noms languages_server_to_client
booléen first_kex_packet_follows
uint32 0 (réservé pour une future extension)

Chaque côté répertorie les paramètres qu’ils sont prêts à 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, selon l’algorithme 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 de serveur sont les algorithmes pris en charge pour la clé d’hôte du serveur. Le serveur définit les algorithmes pour lesquels il possède des 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és qui a été choisie nécessite une clé d’hôte compatible avec le chiffrement ou une signature numérique.

Les deux parties énumèrent les algorithmes à clé symétrique qu’ils sont prêts à accepter, avec les méthodes préférées au sommet. La première option à apparaître sur la liste du client qui se trouve également sur la liste du serveur doit être utilisée. Si aucun accord ne peut être conclu, 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 de authentification du serveur, et cela configure les clés qui seront utilisées pour sécuriser la connexion dans les étapes suivantes. Cela commence généralement par l’envoi 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 un paquet qui correspond aux paramètres de cet algorithme au début.

Si la supposition d’une partie est correcte, ce paquet est utilisé comme premier paquet d’échange de clés. Si aucune des suppositions n’est correcte, 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 responsable de l’établissement d’un secret partagé et d’un hachage. La valeur de hachage de l’échange de clés initial 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és 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 projet Internet de l’IETF (Internet Engineering Task Force), les méthodes d’échange de clés suivantes sont considérées comme sécurisées:

• curve25519-sha256
• curve448-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-group14-sha256
• gss-group15-sha512
• gss-group16-sha512
• gss-group17-sha512
• gss-group18-sha512
• gss-nistp256-sha256
• gss-nistp384-sha384
• gss-nistp521-sha512
• gss-curve25519-sha256
• gss-curve448-sha512
• rsa2048-sha256

Algorithme de clé d’hôte du serveur

Ces algorithmes à clé publique sont utilisés pour l’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 chiffrement et / ou les signatures numériques.
• Une gamme de méthodes d’encodage 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 d’encoder les clés de différentes manières, ainsi qu’une gamme de représentations de certificats.

Les algorithmes par défaut comprennent les éléments suivants, mais il existe également 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 pour crypter les données et assurer la confidentialité. Les paramètres et la clé partagée utilisés dans le processus de chiffrement sont définis dans les phases précédentes de la connexion. L’algorithme choisi chiffre la charge utile, la longueur de paquet, la longueur de 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 être au minimum de 128 bits, mais des clés plus grandes sont préférées.

Algorithmes MAC

Le protocole de transport vé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 dans l’échange de clés), le numéro de séquence de paquet et le contenu du paquet. Il est calculé avant le chiffrement.

Les implémentations doivent offrir un algorithme indépendant pour fonctionner dans chaque direction, bien qu’il soit idéal si le même est utilisé des deux côtés. Une grande variété d’algorithmes d’authentification de message peut être implémentée, mais SHA-256 et supérieur doivent être utilisés dans la plupart des situations pour assurer un haut niveau de sécurité.

Compression

La compression n’est pas obligatoire dans le protocole SSH et ses implémentations doivent permettre aux connexions de se poursuivre sans compression. La compression ne peut être implémentée qu’en option, en utilisant des schémas tels que zlib. Si la compression est utilisée, elle n’affecte que la charge utile. Le MAC et le champ de longueur de paquet sont ensuite calculés en fonction 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 pour authentifier le client. Il peut le faire avec une variété de mécanismes différents, dont beaucoup dépendent de l’ID de session établi dans le protocole de transport. Certains utilisent le chiffrement et les vérifications d’intégrité du protocole de transport conjointement avec l’ID de session, tandis que d’autres utilisent eux-mêmes ces algorithmes.

Le serveur utilise sa politique locale pour décider des méthodes d’authentification qu’il accepte d’un utilisateur individuel. Puisque le serveur a déjà été 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 qu’il exécute par-dessus. Si le protocole de transport ne peut garantir la confidentialité ou vérifier l’intégrité des données, cela limite la façon 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 modifications de mot de passe ne devraient pas être autorisées, car cela donnerait aux attaquants la possibilité de falsifier les données sans être remarqués.

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 à la divulgation du nom d’utilisateur et du mot de passe du client à 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 seulement aussi fort 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 une flexibilité suffisante pour que le client puisse organiser l’utilisation de 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 via son mot de passe (qui doit être chiffré par le protocole de transport). Si le mot de passe correspond à la valeur stockée du serveur, il est accepté et l’authentification avance.
• 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 unique par mot de passe en demandant au serveur de demander des informations au client.

Protocole de connexion

Le protocole de connexion définit comment 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 de la redirection de proxy et de l’accès aux shells.

Le protocole de connexion se trouve 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 transmises. Si le serveur ou le client a été compromis, le protocole de connexion n’est pas sécurisé.

Chaînes

Les canaux sont 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 y a plusieurs canaux, ils sont multiplexés en une seule connexion.

Ouverture des canaux

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 d’ouvrir un canal, elle envoie son numéro de canal dans le cadre du message, ainsi que des informations sur le taille initiale de la fenêtre et le taille maximale des paquets.

La taille de fenêtre initiale 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 des paquets spécifie à quel point un paquet 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’accueillir. Sinon, il enverra un message d’échec. L’ouverture des chaînes peut échouer 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 terminer complètement le canal, elle le fait avec un message de terminaison distinct.

Sécurité SSH

Les différentes versions de SSH ont chacune eu leurs propres problèmes de sécurité, bien que les configurations actuelles de SSH-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 gamme de vulnérabilités différentes. Il s’agit notamment d’un bogue dans SSH 1.5 qui a permis aux 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 avec le détecteur d’attaque de compensation SSH, qui a été intégré dans la plupart des implémentations les plus récentes. Ce correctif est venu avec 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 qui utilise le cryptage IDEA, ainsi qu’une autre qui permet à un serveur compromis de transmettre le processus d’authentification client à un autre serveur..

En raison de ces problèmes de sécurité, SSH-2 doit être utilisé à la place. Pour sécuriser votre mise en œuvre, 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 cryptage par défaut, CBC. Il permet à l’attaquant de récupérer jusqu’à 32 bits du texte en clair à partir d’un bloc chiffré. Cela peut être atténué en utilisant le mode Counter (CTR) et en transformant le chiffrement de bloc en chiffrement de flux à la place.

Fin 2014, Der Spiegel a publié des documents de la NSA qui laissaient entendre que la NSA pouvait parfois briser SSH. Cette fuite NSA PowerPoint déclare que la NSA peut “Récupérer potentiellement des noms d’utilisateur et des mots de passe», Bien qu’aucun autre détail ne soit donné. On ne sait pas quelles méthodes l’agence a utilisées pour ce faire, mais il semble peu probable qu’elle mentirait sur ses capacités dans sa propre documentation interne..

Dans la fuite de Vault 7 en 2023, il a été révélé que la CIA avait 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 CIA. Aucune de ces attaques ne peut rompre le protocole lui-même; ils utilisent simplement d’autres attaques de canaux secondaires qui peuvent contourner cela dans certaines implémentations.

Malgré ces attaques, SSH-2 est considéré comme sûr dans la plupart des situations, tant qu’il est correctement implémenté. Les cibles de grande valeur ou celles qui utilisent des implémentations obsolètes ou médiocres devraient envisager d’autres options.

OpenSSH

Dans OpenSSH version 2, une attaque a été découverte qui a profité d’une faiblesse du paquet binaire SSH. L’attaque a permis à des chercheurs de l’Université de Londres de récupérer 14 bits du texte en clair d’un bloc crypté. Cela a été atténué dans la version 5.2 en faisant lire au protocole l’intégralité d’une longueur de paquet non valide ou d’un code d’authentification de message, 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é accompli grâce à une vulnérabilité d’élévation de privilèges qui a permis 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 a beaucoup de problèmes de sécurité, c’est relatively normal pour un certain nombre de vulnérabilités qui se trouvent dans les différentes implémentations d’un protocole. Cela ne signifie pas que le protocole SSH n’est pas sûr. Au lieu de cela, cela signifie simplement que il doit être mis en œuvre correctement.

Tant que vous utilisez soit SSH-2 ou OpenSSH et il est configuré d’une manière qui convient à votre utilisation, vous devriez avoir confiance en la protection que SSH fournit votre connexion. C’est pourquoi il s’agit toujours d’un protocole si fréquemment utilisé, en particulier à des fins d’accès à distance et de tunneling.

Voir aussi: Types de chiffrement courants expliqués

Fond de technologie de réseau de cyber par TheDigitalArtist sous licence CC0