Pour les articles homonymes, voir SSHD et SSH.

Secure Shell (SSH) est un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés. Il devient donc impossible d'utiliser un analyseur de paquets (sniffer) pour voir ce que fait l'utilisateur.

Le protocole SSH a été conçu avec l'objectif de remplacer les différents protocoles non chiffrés comme rlogin, telnet, rcp et rsh.

Le protocole SSH existe en deux versions majeures : la version 1.0 et la version 2.0.

• La première version permet de se connecter à distance à un ordinateur afin d'obtenir un shell ou ligne de commande. Cette version souffrait néanmoins de problèmes de sécurité dans la vérification de l'intégrité des données envoyées ou reçues, la rendant vulnérable à des attaques actives. En outre, cette version implémentait un système sommaire de transmission de fichiers, et du port tunneling.
• La version 2 qui était à l'état de brouillon jusqu'en janvier 2006 est largement utilisée à travers le monde.

Cette version est beaucoup plus sûre au niveau cryptographique, et possède en plus un protocole de transfert de fichiers complet, le SSH file transfer protocol.

Habituellement le protocole SSH utilise le port TCP 22. Il est particulièrement utilisé pour ouvrir un shell sur un ordinateur distant. Peu utilisé sur les stations Windows (quoiqu'on puisse l'utiliser avec PuTTY, mRemote, cygwin ou encore OpenSSH), SSH fait référence pour l'accès distant sur les stations Linux et Unix.

SSH peut également être utilisé pour transférer des ports TCP d'une machine vers une autre, créant ainsi un tunnel. Cette méthode est couramment utilisée afin de sécuriser une connexion qui ne l'est pas (par exemple le protocole de récupérations de courrier électronique POP3) en la faisant transférer par le biais du tunnel chiffré SSH^[1].

Il est également possible de faire plusieurs sauts entre consoles SSH, c'est-à-dire ouvrir une console sur un serveur, puis, de là, en ouvrir une autre sur un autre serveur^[2].

La première version de SSH (SSH-1) a été conçue par Tatu Ylönen, à Espoo, en Finlande en 1995. Il a créé le premier programme utilisant ce protocole et a ensuite créé une entreprise, SSH Communications Security pour exploiter cette innovation. Cette première version utilisait certains logiciels libres comme la bibliothèque Gnu libgmp, mais au fil du temps ces logiciels ont été remplacés par des logiciels propriétaires. SSH Communications Security a vendu sa licence SSH à F-Secure (anciennement connue sous le nom de Data Fellows).

La version suivante a été nommée SSH-2. Le groupe de travail de l'IETF « secsh » a défini en janvier 2006 le standard Internet SSH-2, que l'on retrouve actuellement dans la plupart des implémentations. Cette version permet une compatibilité ascendante avec les implémentations du brouillon de SSH-2 qui étaient en version 1.99.

En 2023, une alternative à SSH, baptisée SSH3 car elle offre les mêmes services que SSH et s'appuie sur HTTP/3 et QUIC a été proposée^[3].

Avec SSH, l'authentification peut se faire sans l'utilisation de mot de passe ou de phrase secrète en utilisant la cryptographie asymétrique. La clé publique est distribuée sur les systèmes auxquels on souhaite se connecter. La clé privée, qu'on prendra le soin de protéger par un mot de passe, reste uniquement sur le poste à partir duquel on se connecte. L'utilisation d'un « agent ssh » permet de stocker le mot de passe de la clé privée pendant la durée de la session utilisateur.

Cette configuration profite aussi à SCP et à SFTP qui se connectent au même serveur SSH.

Elle est plus sécurisée qu'un mot de passe car elle est plus longue, non générée par l'humain et jamais transmise au serveur. D'ailleurs, il est possible d’interdire la connexion d'un utilisateur par mot de passe en SSH et d'imposer la connexion par clés (comme par défaut pour le compte root de la plupart des distributions Linux)^[4].

Pour créer une clé SSH, on peut utiliser par exemple PuTTY ou MobaXterm sur Windows ou ssh-keygen sur Linux.

Une clé privée ed22519 ressemble à ceci :

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACATbd0/42RFdVJRftYdqw4igZeD1Bp/MZUZBXjCJYgjlQAAAJhFXOsVRVzr
FQAAAAtzc2gtZWQyNTUxOQAAACATbd0/42RFdVJRftYdqw4igZeD1Bp/MZUZBXjCJYgjlQ
AAAEAcHpM/LBPhy5M82GUSIUB0XQ5xjNJQKg5dmcWp5K7PZxNt3T/jZEV1UlF+1h2rDiKB
l4PUGn8xlRkFeMIliCOVAAAADmd1aWxoZW1Ac3NsdnBuAQIDBAUGBw==
-----END OPENSSH PRIVATE KEY-----

Et son empreinte ressemble à ceci :

SHA256:40Nl3InRpXTQPJ6lW66V0Jn385T551Eo1FbILv9M4Jo root@wikipedia

Cette clé est conservée secrète sur la machine cliente. Sur la machine serveur, il convient d'inscrire la clé publique dans le fichier des clés acceptés (souvent stocké dans .ssh/authorized_keys dans le repertoire de l'utilisateur cible). La clé est stockée dans un fichier .pub créé lors de la génération de clé et ressemble à :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBNt3T/jZEV1UlF+1h2rDiKBl4PUGn8xlRkFeMIliCOV root@wikipedia

Contrairement à la clé privée, cette clé peut être librement transmise entre les différentes machines.

Ensuite il est possible d'utiliser la clé privée pour se connecter. Le serveur fera correspondre la connexion avec la clé publique et permettra l'authentification du client.

Le serveur détient aussi des clés privées. Il utilise cette clé et permet donc aux clients d'identifier la clé publique et de savoir si cette dernière est constante au fil du temps. En effet, à la première connexion, l'agent SSH stocke la clé dans un fichier et vérifie que la clé ne change pas. Si la clé change, un message d'alerte indique la différence entre la clé calculée et la clé stockée et demande à l'utilisateur de continuer ou d'abandonner la connexion :

• Soit le serveur a été mis à jour, réinitialisé ou a changé de clés et le changement est légitime. La connexion peut donc être poursuivie.
• Soit un pirate se fait passer pour le serveur pour récupérer des informations confidentielles. La connexion doit être abandonnée.

Ce système de clés hôtes empêche, après la première connexion, les attaques de l'homme du milieu.

Les entrées DNS SSHFP permettent d'enregistrer dans les DNS les clés du serveur et permettent d'établir une comparaison dès la connexion initiale^[5].

• OpenSSH, le projet libre d'outils SSH. OpenSSH est l'implémentation ssh la plus utilisée, y compris par les distributions GNU/Linux.
• Portable OpenSSH, une implémentation OpenSSH multiplateforme.
• Dropbear^[6], une implémentation libre ayant pour but de remplacer OpenSSH sur les systèmes Unix ayant peu de ressources (processeur, mémoire, etc.) comme les systèmes embarqués.
• PuTTY, un client SSH multi-OS.
• TTyEmulator, un émulateur de terminal propriétaire pour Windows

• Protocole de communication
• SSH File Transfer Protocol (soit SSH FTP) transfert de fichiers à travers SSH
• Secure shell file system (soit SSHFS) partage de systèmes de fichiers à travers SSH
• Secure copy : transfert de fichiers à travers SSH
• Files transferred over shell protocol (en) : transfert de fichiers à travers SSH
• Enregistrement DNS SSHFP

• RFC 4251 : Architecture générale du protocole
• RFC 4252 : Protocole d'authentification (PKI, par mot de passe ou par machine)
• RFC 4253 : Protocole de transport sécurisé (Chiffrement, Signature numérique, intégrité)
• RFC 4254 : Protocole de connexion (Port tunneling, Shell)

• Portail de la sécurité des systèmes d'information
• Portail de la cryptologie