Secure Shell

Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication et transfert de fichier, sécurisé et chiffré

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.

Secure Shell

Informations
Fonction Session à distance sécurisée
Sigle SSH
Date de création 1995
Port TCP/22
RFC RFC 4250, RFC 4251 , RFC 4252, RFC 4253, RFC 4254

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

modifier

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 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].

Historique

modifier

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 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].

SSH avec authentification par clés

modifier

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].

Clés SSH : principe de fonctionnement

modifier

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.

Sécurisation par la vérification des clés hôtes

modifier

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].

Implémentations logicielles

modifier
  • 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

Notes et références

modifier
  1. (en) Linuxize, « How to setup SSH tunnelling » Accès libre, (consulté le )
  2. « Comment utiliser SSH ProxyJump et SSH ProxyCommand sous Linux », sur fr.linux-console.net (consulté le )
  3. (en-US) François Michel, « Towards SSH3: How HTTP/3 improves secure shells », sur APNIC Blog, (consulté le )
  4. (en) Lubos Rendek, « Enabling SSH Root Login on Ubuntu/Debian Linux Servers » Accès libre, sur linuxconfig.org, (consulté le )
  5. Wesley Griffin et Jakob Schlyter, « Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints », Internet Engineering Task Force, (DOI 10.17487/rfc4255, consulté le )
  6. (en) Dropbear.

Voir aussi

modifier

Sur les autres projets Wikimedia :

Articles connexes

modifier

Liens externes

modifier