Table des matières

• 4.4. Secure Shell (SSH)
  • 4.4.1. Historique et objectifs
  • 4.3.2. Fonctionnement
    • Etablissement du canal chiffré
    • Authentification
  • 4.3.3. Tunnelling SSH
  • Bibliographie

4.4. Secure Shell (SSH)

4.4.1. Historique et objectifs

A l’époque des mainframes et des premiers réseaux, le besoin de communiquer à distance avec des ordinateurs distants est apparu. Différents protocoles ont été proposés pour répondre à ce besoin, dont le protocole telnet [1], ou encore rlogin, rsh ou FTP.

Telnet tourne par dessus TCP et les serveurs telnet utilisent le port 23 par défaut. Il permet l’échange de données textuelles (caractères) bidirectionnel d’un terminal à un autre terminal distant. Il a été longtemps utilisé, mais souffre d’une limitation critique à l’heure actuelle : l’absence d’authentification et de garantie de confidentialité. Toutes les données échangées durant un échange telnet passent en effet en clair, y compris les informations critiques comme les mots de passe. Avec le temps, l’Internet s’est étendu et des usages commerciaux sont apparus, ainsi que les premières problématiques liées à la sécurité. Le besoin de confidentialité des échanges est rapidement apparu.

En 1995, une alternative sécurisée à telnet et aux autres protocoles similaires a été proposée : le Secure Shell Protocol (SSH). Son objectif est d’offrir la confidentialité et l’intégrité des échanges, ainsi qu’un mécanisme d’authentification côté serveur et côté client.

SSH a été standardisé par l’IETF en 2006, dans sa seconde version SSH-2. Cette nouvelle version, incompatible avec la version 1, apporte des améliorations au niveau de la sécurité et des fonctionnalités.

Au fil du temps, une implémentation Open Source du protocole SSH s’est imposée sur Internet : OpenSSH. Cette suite logicielle développée dans le cadre du projet OpenBSD fournit divers outils en plus du shell distant ssh: scp, sftp, ssh-agent, ssh-keygen, le serveur sshd …

4.3.2. Fonctionnement

Une fois la connexion TCP ouverte, l’établissement d’une session SSH s’effectue en deux étapes :

1. L’établissement d’un canal sécurisé, pour garantir la confidentialité des échanges.
2. L’authentification de l’utilisateur et la vérification de ses droits d’accès.

Etablissement du canal chiffré

Pour pouvoir chiffrer efficacement les données, SSH va se baser sur le chiffrement symétrique. Cette technique nécessitant, comme vu à la section 4.2., le partage préalable d’une clé secrète, SSH effectuera donc une procédure de partage de secret en utilisant la cryptographie asymétrique, ce qui permet d’éviter de devoir utiliser un canal parallèle.

1. Pour pouvoir établir un canal chiffré, il faut que le client et le serveur se mettent d’accord sur la méthode à utiliser. Comme les algorithmes évoluent au fil du temps, il est important que le protocole SSH puisse s’adapter, ce que permet cette négociation de paramètres.
2. Une fois les paramètres fixés, le serveur envoie sa clé publique au client. Ce dernier peut vérifier qu’il s’agit de l’hôte attendu, par exemple en vérifiant avec les clés publiques stockées précédemment, ou en vérifiant son hash auprès de l’administrateur du réseau.
3. Le client et le serveur effectuent une variante d’un échange de clé Diffie-Hellman, pour aboutir à un secret commun partagé.

Authentification

L’authentification du serveur se fait sur base de la clé publique, lors de l’étape précédente. Elle ne doit pas être prise à la légère : un serveur malveillant peut facilement se faire passer pour un autre, simplement en envoyant sa propre clé publique! Il est donc important de toujours vérifier que la clé publique est adéquate. S’il s’agit d’un serveur sur lequel on se connecte fréquemment, ssh lancera un message d’alerte en cas de changement de clé publique. Si c’est la première fois que l’on s’y connecte, ssh affichera un avertissement invitant à vérifier le fingerprint/hash de la nouvelle clé.

Quant au client, il est authentifié une fois que la communication est chiffrée. Deux méthodes sont utilisées en général :

• L’utilisation d’un login et d’un mot de passe
• L’utilisation de clés d’authentification SSH.

La première méthode est bien moins sécurisée, car dépendante de la force du mot de passe, et sujette aux attaques de type dictionnaire ou brute-force. On lui préférera donc la seconde méthode, utilisant des clés cryptographiques.

L’authentification par clé SSH se base à nouveau sur la cryptographie asymétrique : pour authentifier un client, on va demander à ce dernier de déposer sa clé publique sur le serveur distant. Ensuite, pour l’authentification, le serveur va générer un nombre aléatoire qu’il chiffrera avec la clé publique du client. Il envoie ensuite ce message chiffré au client, et lui demande de le déchiffrer et de lui renvoyer la réponse (en pratique, un hash de la réponse). Si cette dernière correspond au nombre aléatoire utilisé, le serveur a la garantie qu’il s’agit bien du client légitime puisque seul lui était en mesure de déchiffrer ce message.

4.3.3. Tunnelling SSH

SSH est pratique pour ouvrir un terminal distant, mais il propose également d’autres fonctionnalités intéressantes, comme notamment le tunnelling. L’idée est de profiter du canal sécurisé pour faire transiter d’autres communications réseau non-sécurisée et garantir ainsi la confidentialité des échanges. Un tunnel SSH fait un peu office de VPN pour une application spécifique.

Dans l’exemple illustré dans l’image, un utilisateur souhaite accéder à un serveur SMTP non sécurisé de son entreprise, mais il se trouve actuellement en déplacement, sur un réseau non sécurisé. S’il ne dispose pas d’un VPN d’entreprise complet, il peut utiliser un tunnel SSH pour garantir la confidentialité de ses échanges d’emails.

La commande ci-dessous permet d’ouvrir un tel tunnel :

ssh -L 2000:smtp.mail.com:25 toto@ssh.exemple.org

Elle indique que tout le traffic envoyé sur le port 2000 du poste client sera transféré, via le serveur ssh ssh.exemple.org, au serveur SMTP smtp.mail.com. Entre le poste client et le serveur SSH, la communication smtp sera chiffrée.

Pour utiliser le tunnel, l’utilisateur n’a plus qu’à configurer son client mail pour utiliser l’adresse localhost et le port 2000 pour l’envoi des emails.

Bibliographie

[1] Network Working Group, IETF, RFC854 : Telnet Protocol Specification, 1983, consulté en février 2024

[2] O. Bonaventure, Computer Networking : Principles, Protocols and Practice, chap. Remote Login, consulté en février 2024

[3] J. Ellingwood, tutoriel Digital Ocean, Understanding the SSH Encryption and Connection Process, fév. 2022, consulté en fév. 2024