Internet permet de réaliser un grand nombre d’opérations à distance, notamment l’administration de serveurs ou bien le transfert de fichiers. Le protocole Telnet et les r-commandes BSD (rsh, rlogin et rexec) permettant d’effectuer ces tâches distantes possèdent l’inconvénient majeur de faire circuler en clair sur le réseau les informations échangées, notamment l’identifiant (login) et le mot de passe pour l’accès à la machine distante. Ainsi, un pirate situé sur un réseau entre l’utilisateur et la machine distante a la possibilité d’écouter le traffic, c’est-à-dire d’utiliser un outil appelé sniffer capable de capturer les trames circulant sur le réseau et ainsi d’obtenir l’identifiant et le mot de passe d’accés à la machine distante.
Même si les informations échangées ne possèdent pas un grand niveau de sécurité, le pirate obtient un accès à un compte sur la machine distante et peut éventuellement étendre ses privilèges sur la machine afin d’obtenir un accès administrateur (root).
Etant donné qu’il est impossible de maîtriser l’ensemble des infrastructures physiques situées entre l’utilisateur et la machine distante (internet étant par définition un réseau ouvert), la seule solution est de recourir à une sécurité au niveau logique (au niveau des données).
Le protocole SSH (Secure Shell) répond à cette problématique en permettant à des utilisateurs (ou bien des services TCP/IP) d’accéder à une machine à travers une communication chiffrée (appelée tunnel).
– Le protocole SSH
Le protocole SSH (Secure Shell) a été mis au point en 1995 par le Finlandais Tatu Ylönen.
Il s’agit d’un protocole permettant à un client (un utilisateur ou bien même une machine) d’ouvrir une session interactive sur une machine distante (serveur) afin d’envoyer des commandes ou des fichiers de manière sécurisée :
* Les données circulant entre le client et le serveur sont chiffrées, ce qui garantit leur confidentialité (personne d’autre que le serveur ou le client ne peut lire les informations transitant sur le réseau). Il n’est donc pas possible d’écouter le réseau à l’aide d’un analyseur de trames.
* Le client et le serveur s’authentifient mutuellement afin d’assurer que les deux machines qui communiquent sont bien celles que chacune des parties croit être. Il n’est donc plus possible pour un pirate d’usurper l’identité du client ou du serveur (spoofing).
La version 1 du protocole (SSH1) proposée dès 1995 avait pour but de servir d’alternative aux sessions interactives (shells) telles que Telnet, rsh, rlogin et rexec. Ce protocole possèdait toutefois une faille permettant à un pirate d’insérer des données dans le flux chiffré. C’est la raison pour laquelle en 1997 la version 2 du protocole (SSH2) a été proposée en tant que document de travail (draft) à l’IETF. Les documents définissant le protocole sont accessibles en ligne sur http://www.ietf.org/html.charters/secsh-charter.html.
Secure Shell Version 2 propose également une solution de transfert de fichiers sécurisé (SFTP, Secure File Transfer Protocol).
SSH est un protocole, c’est-à-dire une méthode standard permettant à des machines d’établir une communication sécurisée. A ce titre, il existe de nombreuses implémentations de clients et de serveurs SSH. Certains sont payants, d’autres sont gratuits ou open source : vous trouverez un certain nombre de clients SSH dans la section téléchargement de CommentCaMarche.
– Fonctionnement de SSH
L’établissement d’une connexion SSH se fait en plusieurs étapes :
* Dans un premier temps le serveur et le client s’identifient mutuellement afin de mettre en place un canal sécurisé (couche de transport sécurisée).
* Dans un second temps le client s’authentifie auprès du serveur pour obtenir une session.
– Mise en place du canal sécurisé
La mise en place d’une couche de transport sécurisée débute par une phase de négociation entre le client et le serveur afin de s’entendre sur les méthodes de chiffrement à utiliser. En effet le protocole SSH est prévu pour fonctionner avec un grand nombre d’algorithmes de chiffrement, c’est pourquoi le client et le serveur doivent dans un premier temps échanger les algorithmes qu’ils supportent.
Ensuite, afin d’établir une connexion sécurisée, le serveur envoie sa clé publique d’hôte (host key) au client. Le client génère une clé de session de 256 bits qu’il chiffre grâce à la clé publique du serveur, et envoie au serveur la clé de session chiffrée ainsi que l’algorithme utilisé. Le serveur déchiffre la clé de session grâce à sa clé privée et envoie un message de confirmation chiffré à l’aide de la clé de session. A partir de là le reste des communications est chiffré grâce à un algorithme de chiffrement symétrique en utilisant la clé de session partagée par le client et le serveur.
Toute la sécurité de la transaction repose sur l’assurance qu’ont le client et le serveur de la validité des clés d’hôte de l’autre partie. Ainsi, lors de la première connexion à un serveur, le client affiche généralement un message demandant d’accepter la connexion (et présente éventuellement un condensé de la clé d’hôte du serveur) :
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no) ?
Afin d’obtenir une session véritablement sécurisée, il est conseillé de demander oralement à l’administrateur du serveur de valider la clé publique présentée. Si l’utilisateur valide la connexion, le client enregistre la clé hôte du serveur afin d’éviter la répétition de cette phase.
A l’inverse, selon sa configuration, le serveur peut parfois vérifier que le client est bien celui qu’il prétend être. Ainsi, si le serveur possède une liste d’hôtes autorisés à se connecter, il va chiffrer un message à l’aide de la clé publique du client (qu’il possède dans sa base de données de clés d’hôtes) afin de vérifier si le client est en mesure de le déchiffrer à l’aide de sa clé privée (on parle de challenge).
– L’authentification
Une fois que la connexion sécurisée est mise en place entre le client et le serveur, le client doit s’identifier sur le serveur afin d’obtenir un droit d’accès. Il existe plusieurs méthodes :
* la méthode la plus connue est le traditionnel mot de passe. Le client envoie un nom d’utilisateur et un mot de passe au serveur au travers de la communication sécurisé et le serveur vérifie si l’utilisateur concerné a accès à la machine et si le mot de passe fourni est valide
* une méthode moins connue mais plus souple est l’utilisation de clés publiques. Si l’authentification par clé est choisie par le client, le serveur va créer un challenge et donner un accès au client si ce dernier parvient à déchiffrer le challenge avec sa clé privée