Le protocole Secure Shell ( protocole SSH ) est un protocole réseau cryptographique permettant d'exploiter des services réseau de manière sécurisée sur un réseau non sécurisé . ...
Étant donné que des mécanismes comme Telnet et Remote Shell sont conçus pour accéder à des ordinateurs distants et les exploiter, l'envoi non sécurisé des jetons d'authentification ( nom d'utilisateur et mot de passe, par exemple ) nécessaires à cet accès via un réseau public présente un risque important de fuite du mot de passe par des tiers, leur permettant ainsi d'obtenir le même niveau d'accès au système distant que l'utilisateur Telnet. Secure Shell atténue ce risque grâce à l'utilisation de mécanismes de chiffrement destinés à masquer le contenu de la transmission à un observateur, même si ce dernier a accès à l'intégralité du flux de données .
En 1995, l'informaticien finlandais Tatu Ylönen conçoit SSH et en propose une implémentation sous la forme de deux commandes, `ssh` et `slogin` , remplaçant de manière sécurisée `rsh` et `rlogin` , respectivement. Le développement ultérieur de cette suite de protocoles s'est poursuivi au sein de plusieurs groupes de développeurs, donnant lieu à diverses variantes d'implémentation. La spécification du protocole distingue deux versions principales : SSH-1 et SSH-2. La pile logicielle la plus couramment utilisée est OpenSSH , publiée en 1999 en tant que logiciel libre par les développeurs d'OpenBSD . Des implémentations sont disponibles pour tous les types de systèmes d'exploitation courants, y compris les systèmes embarqués .
Les applications SSH sont basées sur une architecture client-serveur , connectant une instance client SSH à un serveur SSH . SSH fonctionne comme une suite de protocoles en couches comprenant trois composants hiérarchiques principaux : la couche transport assure l’authentification du serveur, la confidentialité et l’intégrité ; le protocole d’authentification de l’utilisateur valide l’utilisateur auprès du serveur ; et le protocole de connexion multiplexe le tunnel chiffré en plusieurs canaux de communication logiques.
la cryptographie à clé publique pour authentifier l'ordinateur distant et lui permettre d'authentifier l'utilisateur, si nécessaire.
Le protocole SSH peut être utilisé selon plusieurs méthodes. Dans la plus simple, les deux extrémités d'un canal de communication utilisent des paires de clés publique/privée générées automatiquement pour chiffrer la connexion réseau, puis un mot de passe pour authentifier l'utilisateur.
Lorsque l'utilisateur génère manuellement une paire de clés publique/privée, l'authentification est effectuée dès la création de cette paire, et une session peut alors s'ouvrir automatiquement sans saisie de mot de passe. Dans ce cas, la clé publique est placée sur tous les ordinateurs autorisés à accéder au propriétaire de la clé privée correspondante, laquelle reste confidentielle. Bien que l'authentification repose sur la clé privée, celle-ci n'est jamais transmise sur le réseau. SSH vérifie uniquement que la personne fournissant la clé publique est bien la propriétaire de la clé privée correspondante.
Dans toutes les versions de SSH, il est essentiel de vérifier les clés publiques inconnues , c'est-à-dire de les associer à des identités , avant de les accepter comme valides. Accepter la clé publique d'un attaquant sans validation reviendrait à autoriser un attaquant non autorisé à se connecter en tant qu'utilisateur légitime.
Authentification : gestion des clés OpenSSH
Sur les systèmes de type Unix , la liste des clés publiques autorisées est généralement stockée dans le répertoire personnel de l'utilisateur autorisé à se connecter à distance, dans le fichier `/etc/ssh` ~/.ssh/authorized_keys. Ce fichier n'est pris en compte par SSH que s'il n'est accessible en écriture que par son propriétaire et l'utilisateur root. Lorsque la clé publique est présente sur le serveur distant et que la clé privée correspondante est présente sur le serveur local, la saisie du mot de passe n'est plus nécessaire. Toutefois, pour une sécurité renforcée, la clé privée peut être protégée par une phrase secrète.
La clé privée peut également être recherchée à des emplacements standards, et son chemin complet peut être spécifié en ligne de commande (option -ipour ssh). L' utilitaire ssh-keygen génère les clés publique et privée, toujours par paires.
Utiliser
Le protocole SSH est généralement utilisé pour se connecter à l' interface de ligne de commande (CLI) d'un ordinateur distant et pour exécuter des commandes sur un serveur distant. Il prend également en charge les mécanismes de tunnelisation , de redirection des ports TCP et des connexions X11 , et peut être utilisé pour transférer des fichiers à l'aide des protocoles SFTP ( SSH File Transfer Protocol ) ou SCP ( Secure Copy Protocol ) associés.
Les gestionnaires de fichiers pour systèmes de type UNIX (par exemple, Konqueror ) peuvent utiliser le protocole FISH pour proposer une interface graphique à deux volets avec glisser-déposer. Le logiciel libre WinSCP pour Windows offre des fonctionnalités similaires de gestion de fichiers (synchronisation, copie, suppression à distance) grâce à PuTTY . WinSCP et PuTTY sont disponibles sous forme de paquets exécutables directement depuis une clé USB, sans installation requise sur la machine cliente. Crostini sur ChromeOS intègre OpenSSH par défaut. Configurer un serveur SSH sous Windows implique généralement d'activer une option dans l'application Paramètres.
Le protocole SSH est important dans le cloud computing pour résoudre les problèmes de connectivité et éviter les problèmes de sécurité liés à l'exposition directe d'une machine virtuelle hébergée dans le cloud sur Internet. Un tunnel SSH peut fournir un chemin sécurisé via Internet, à travers un pare-feu, vers une machine virtuelle.
L' IANA a attribué les ports TCP 22, UDP 22 et SCTP 22 à ce protocole. L'IANA avait déjà répertorié le port TCP standard 22 pour les serveurs SSH parmi les ports les plus connus dès 2001. SSH peut également être exécuté en utilisant SCTP plutôt que TCP comme protocole de couche transport orienté connexion.
développement historique
Version 1
En 1995, Tatu Ylönen , chercheur à l'Université de technologie d'Helsinki en Finlande, a conçu la première version du protocole (désormais appelée SSH-1 ) suite à une attaque par interception de mots de passe sur le réseau de son université . L'objectif de SSH était de remplacer les protocoles antérieurs rlogin , telnet , FTP et rsh , qui n'offraient ni authentification forte ni garantie de confidentialité. Il a choisi le numéro de port 22 car il se situe entre telnetles ports 23 et ftp21.
Ylönen a publié son implémentation en tant que logiciel gratuit en juillet 1995, et l'outil a rapidement gagné en popularité. Vers la fin de 1995, la base d'utilisateurs SSH avait atteint 20 000 utilisateurs dans cinquante pays.
En décembre 1995, Ylönen a fondé SSH Communications Security pour commercialiser et développer SSH. La version originale du logiciel SSH utilisait divers logiciels libres , tels que GNU libgmp , mais les versions ultérieures publiées par SSH Communications Security sont devenues de plus en plus propriétaires .
On estimait qu'en 2000, le nombre d'utilisateurs avait atteint 2 millions.
Version 2
En 2006, après avoir été discutée au sein d'un groupe de travail nommé « secsh » une version révisée du protocole SSH, SSH-2, a été adoptée comme norme . Cette version offre une sécurité renforcée et de nouvelles fonctionnalités, mais n'est pas compatible avec SSH-1. Par exemple, elle introduit de nouveaux mécanismes d'échange de clés comme l'échange de clés Diffie-Hellman , ainsi qu'un contrôle d' intégrité des données amélioré grâce à des codes d'authentification de message tels que MD5 ou SHA-1 , qui peuvent être négociés entre le client et le serveur. SSH-2 ajoute également des méthodes de chiffrement plus robustes comme AES , qui a progressivement remplacé les algorithmes de chiffrement plus faibles et compromis de la norme précédente , tels que 3DES Parmi les nouvelles fonctionnalités de SSH-2 figure la possibilité d'exécuter un nombre illimité de sessions shell sur une seule connexion SSH. En raison de la supériorité et de la popularité de SSH-2 sur SSH-1, certaines implémentations telles que libssh (v0.8.0+), Lsh et Dropbear ont finalement pris en charge uniquement le protocole SSH-2.
Version 1.99
En janvier 2006, bien après l'établissement de la version 2.1, la RFC 4253 a spécifié qu'un serveur SSH prenant en charge la version 2.0 ainsi que les versions antérieures devait identifier sa version de protocole comme étant 1.99. Ce numéro de version ne reflète pas une révision historique du logiciel, mais une méthode pour identifier la rétrocompatibilité .
licence open source . Ce code a servi de base au logiciel OSSH de Björn Grönvall . Peu après, les développeurs d'OpenBSD ont créé une branche (fork) du code de Grönvall et ont développé OpenSSH , intégré à la version 2.6 d'OpenBSD. À partir de cette version, une branche « portabilité » a été créée pour porter OpenSSH sur d'autres systèmes d'exploitation
[ continue d'être maintenu et prend en charge le protocole SSH-2, la prise en charge de SSH-1 ayant été supprimée du code source dans la version 7.6.
Avenir
En 2023, une alternative au protocole SSH traditionnel a été proposée sous le nom de SSH3 par le doctorant François Michel et le professeur Olivier Bonaventure, et son code source a été rendu libre . Cette nouvelle version implémente le protocole de connexion SSH original, mais fonctionne sur HTTP/3 , qui s'exécute sur QUIC . Elle offre de nombreuses fonctionnalités, telles que :
Établissement de session plus rapide, réduisant le nombre de retards aller-retour de 5-7 à 3.
Haute sécurité : alors que SSHv2 repose sur ses propres protocoles, SSH3 exploite TLS 1.3 , QUIC et HTTP .
Redirection de port UDP
Certificats X.509
OpenID Connect
Cependant, le nom SSH3 fait débat, et le projet vise à se renommer pour un nom plus approprié. Ce débat est motivé par le fait que cette nouvelle implémentation modifie considérablement le protocole SSH, ce qui suggère qu'elle ne devrait pas être appelée SSH3.
Utilisations
Exemple de tunnelisation d'une application X11 via SSH : l'utilisateur « josh » s'est connecté en SSH depuis la machine locale « foofighter » vers la machine distante « tengwar » pour exécuter xeyes .Connexion à OpenWrt via SSH en utilisant PuTTY exécuté sous Windows .
SSH est un protocole utilisable par de nombreuses applications sur diverses plateformes, notamment la plupart des systèmes Unix ( Linux , les BSD, y compris macOS d' Apple , et Solaris ), ainsi que Microsoft Windows . Certaines des applications mentionnées ci-dessous peuvent nécessiter des fonctionnalités disponibles ou compatibles uniquement avec des clients ou serveurs SSH spécifiques. Par exemple, il est possible d'utiliser le protocole SSH pour implémenter un VPN , mais actuellement uniquement avec l' implémentation serveur et client OpenSSH .
Pour se connecter à un shell sur un hôte distant (en remplacement de Telnet et rlogin )
Pour exécuter une seule commande sur un hôte distant (en remplacement de rsh )
Pour configurer une connexion automatique (sans mot de passe) à un serveur distant (par exemple, en utilisant OpenSSH )
En combinaison avec rsync pour sauvegarder, copier et dupliquer des fichiers de manière efficace et sécurisée
Le protocole rapide et sécurisé (FASP), également connu sous le nom d'Aspera , utilise SSH pour le contrôle et les ports UDP pour le transfert de données.
Diagramme du paquet binaire SSH-2.
Le protocole SSH possède une architecture en couches avec trois composants distincts :
La couche transport ( RFC 4253 ) utilise généralement le protocole TCP (Transmission Control Protocol ) du protocole TCP/IP , en réservant le port 22 comme port d'écoute du serveur. Cette couche gère l'échange initial de clés ainsi que l'authentification du serveur et configure le chiffrement, la compression et la vérification d'intégrité. Elle expose à la couche supérieure une interface permettant l'envoi et la réception de paquets en clair d'une taille maximale de 32 768 octets chacun, cette taille pouvant être supérieure selon l'implémentation. La couche transport organise également le renouvellement des clés, généralement après le transfert de 1 Go de données ou après une heure, selon la première éventualité.
La couche d'authentification utilisateur ( RFC 4252 ) gère l'authentification du client et propose un ensemble d'algorithmes d'authentification. L'authentification est pilotée par le client : lorsqu'un mot de passe est demandé, c'est généralement le client SSH qui pose la question, et non le serveur. Le serveur se contente de répondre aux requêtes d'authentification du client. Parmi les méthodes d'authentification utilisateur couramment utilisées, on peut citer :
Mot de passe : méthode d’authentification simple par mot de passe, incluant une fonctionnalité permettant de modifier le mot de passe. Cette méthode n’est pas implémentée par tous les programmes.
Interaction par clavier ( RFC 4256 ) : méthode polyvalente où le serveur envoie une ou plusieurs invites à saisir des informations ; le client les affiche et renvoie les réponses saisies par l’utilisateur. Utilisée pour l’ authentification par mot de passe à usage unique, comme S/Key ou SecurID . Dans certaines configurations OpenSSH, lorsque PAM est le fournisseur d’authentification sous-jacent, elle sert à l’authentification par mot de passe, ce qui peut parfois empêcher la connexion avec un client prenant uniquement en charge cette méthode.
Les méthodes d'authentification GSSAPI offrent un schéma extensible pour l'authentification SSH via des mécanismes externes tels que Kerberos 5 ou NTLM , permettant ainsi l'authentification unique (SSO) pour les sessions SSH. Ces méthodes sont généralement implémentées par les solutions SSH commerciales pour une utilisation en entreprise, bien qu'OpenSSH propose une implémentation GSSAPI fonctionnelle.
La couche de connexion ( RFC 4254 ) définit les concepts de canaux, de requêtes de canal et de requêtes globales, qui définissent les services SSH fournis. Une connexion SSH unique peut être multiplexée simultanément en plusieurs canaux logiques, chacun assurant un transfert de données bidirectionnel. Les requêtes de canal servent à relayer des données hors bande spécifiques au canal, telles que la modification de la taille d'une fenêtre de terminal ou le code de sortie d'un processus côté serveur. De plus, chaque canal effectue son propre contrôle de flux en fonction de la taille de sa fenêtre de réception. Le client SSH demande l'ouverture d'un port côté serveur via une requête globale. Les types de canaux standard incluent :
shell pour les shells de terminal, SFTP et les requêtes exec (y compris les transferts SCP)
direct-tcpip pour les connexions transférées client-serveur
forwarded-tcpip pour les connexions transférées serveur-client
L' enregistrement DNS SSHFP (RFC 4255) fournit les empreintes de clés publiques de l'hôte afin de faciliter la vérification de l'authenticité de l'hôte.
Cette architecture ouverte offre une grande flexibilité, permettant d'utiliser SSH à diverses fins, au-delà d'un simple shell sécurisé. Les fonctionnalités de la couche transport sont comparables à celles de TLS ; la couche d'authentification utilisateur est hautement extensible grâce à des méthodes d'authentification personnalisées ; et la couche connexion permet de multiplexer plusieurs sessions secondaires au sein d'une même connexion SSH, une fonctionnalité comparable à BEEP et absente de TLS.
En 1998, une vulnérabilité a été décrite dans SSH 1.5. Cette vulnérabilité permettait l'insertion non autorisée de contenu dans un flux SSH chiffré, en raison d'une protection insuffisante de l'intégrité des données par le CRC-32 utilisé dans cette version du protocole. Un correctif, appelé SSH Compensation Attack Detector a été intégré à la plupart des implémentations. Cependant, nombre de ces implémentations mises à jour contenaient une nouvelle vulnérabilité de dépassement d'entier permettant à des attaquants d'exécuter du code arbitraire avec les privilèges du démon SSH, généralement ceux de root.
En janvier 2001, une vulnérabilité a été découverte permettant à des attaquants de modifier le dernier bloc d'une session chiffrée avec IDEA . Le même mois, une autre vulnérabilité a été découverte, permettant à un serveur malveillant de transférer l'authentification d'un client à un autre serveur.
Étant donné que SSH-1 présente des défauts de conception inhérents qui le rendent vulnérable, il est désormais généralement considéré comme obsolète et doit être évité en désactivant explicitement le basculement vers SSH-1. La plupart des serveurs et clients modernes prennent en charge SSH-2.
Récupération de texte clair CBC
En novembre 2008, une vulnérabilité théorique a été découverte dans toutes les versions de SSH, permettant de récupérer jusqu'à 32 bits de texte clair à partir d'un bloc de texte chiffré utilisant le mode de chiffrement standard par défaut de l'époque, CBC . La solution la plus simple consiste à utiliser le mode CTR (Counter Mode) au lieu du mode CBC, car cela rend SSH résistant à cette attaque.
Décryptage suspecté par la NSA
Le 28 décembre 2014, Der Spiegel a publié des informations classifiées divulguées par le lanceur d'alerte Edward Snowden , suggérant que la NSA pourrait être en mesure de déchiffrer une partie du trafic SSH. Les détails techniques associés à un tel processus n'ont pas été divulgués. Une analyse de 2017 des outils de piratage de la CIA , BothanSpy et Gyrfalcon, a suggéré que le protocole SSH n'était pas compromis.
Attaque de tortue
attaque Terrapin » . Toutefois, le risque est atténué par la nécessité d'intercepter une session SSH légitime et par la portée limitée de l'attaque, qui se traduit fortuitement le plus souvent par des échecs de connexion . Les développeurs SSH ont indiqué que l'impact majeur de cette attaque est de dégrader les fonctionnalités d'obfuscation du timing des frappes au clavier . La vulnérabilité a été corrigée dans OpenSSH 9.6, mais la mise à niveau du client et du serveur est indispensable pour une correction optimale.
RFC 4253 – Protocole de couche transport Secure Shell (SSH)
RFC 4254 – Protocole de connexion Secure Shell (SSH)
RFC 4255 – Utilisation du DNS pour publier de manière sécurisée les empreintes de clés Secure Shell (SSH)
RFC 4256 – Authentification générique des échanges de messages pour le protocole Secure Shell (SSH)
RFC 4335 – Extension de la fonction de rupture de canal de session Secure Shell (SSH)
RFC 4344 – Modes de chiffrement de la couche transport Secure Shell (SSH)
RFC 4345 – Modes Arcfour améliorés pour le protocole de couche transport Secure Shell (SSH)
Les spécifications du protocole ont été ultérieurement mises à jour par les publications suivantes :
RFC 4419 – Échange de groupes Diffie-Hellman pour le protocole de couche transport Secure Shell (SSH) (mars 2006)
RFC 4432 – Échange de clés RSA pour le protocole de couche transport Secure Shell (SSH) (mars 2006)
RFC 4462 – Interface de programmation d'application de service de sécurité générique (GSS-API) Authentification et échange de clés pour le protocole Secure Shell (SSH) (mai 2006)
RFC 4716 – Format de fichier de clé publique Secure Shell (SSH) (novembre 2006)
RFC 6239 – Suite B Suites cryptographiques pour Secure Shell (SSH) (mai 2011)
RFC 6594 – Utilisation de l’algorithme SHA-256 avec RSA, l’algorithme de signature numérique (DSA) et le DSA à courbe elliptique (ECDSA) dans les enregistrements de ressources SSHFP (avril 2012)
RFC 6668 – Vérification de l'intégrité des données SHA-2 pour le protocole de couche transport Secure Shell (SSH) (juillet 2012)
RFC 7479 – Ed25519 Enregistrements de ressources SSHFP (mars 2015)
RFC 5592 – Modèle de transport Secure Shell pour le protocole de gestion de réseau simple (SNMP) (juin 2009)
RFC 6242 – Utilisation du protocole NETCONF sur Secure Shell (SSH) (juin 2011)
RFC 8332 – Utilisation des clés RSA avec SHA-256 et SHA-512 dans le protocole Secure Shell (SSH) (mars 2018)
RFC 8709 – Ed25519 et Ed448 Algorithmes de clés publiques pour le protocole Secure Shell (SSH) (février 2020)
draft-gerhards-syslog-transport-ssh – Mappage du transport SSH pour SYSLOG (juillet 2006)
draft-ietf-secsh-filexfer – Protocole de transfert de fichiers SSH (juillet 2006)
Worldlex Wiki 
