18.3. Séquence des événements d'une connexion SSH

Pour aider à protéger l'intégrité d'une communication SSH entre deux ordinateurs hôtes, la série suivante d'événements doit être utilisée.

18.3.1. Couche transport

Le rôle principal d'une couche transport est de faciliter une communication sécurisée entre deux hôtes non seulement au moment de l'authentification, mais également après. Pour ce faire, la couche transport traite le cryptage et décryptage de données et offre la protection de l'intégrité des paquets de données lors de leur envoi et de leur réception. De plus, la couche transport effectue la compression des données permettant l'accélération la vitesse de transfert d'information.

Lorsqu'un client communique avec un serveur au moyen d'un protocole SSH, de nombreux éléments importants sont négociés afin que les deux systèmes puissent créer correctement la couche transport. Les opérations ci-dessous ont lieu durant cet échange:

Durant l'échange des clés, le serveur s'identifie au client au moyen d'une clé d'hôte unique. Évidemment, si le client communique pour la première fois avec ce serveur, la clé du serveur ne sera pas connue du client et la connexion ne pourra être établie. OpenSSH contourne ce problème en acceptant la clé d'hôte du serveur après notification de l'utilisateur et vérifie l'acceptation de la nouvelle clé d'hôte. Lors des connexions suivantes, la clé d'hôte du serveur peut être vérifiée au moyen d'une version enregistrée sur le client, permettant ainsi au client de s'assurer qu'il communique bien avec le serveur désiré. Si, à l'avenir, la clé d'hôte n'est plus valide, l'utilisateur doit supprimer la version sauvegardée du client avant qu'une nouvelle connexion ne puisse avoir lieu.

CautionAttention
 

Un pirate pourrait se faire passer pour le serveur SSH lors de la première connexion car le système local ne reconnaît aucune différence entre le serveur désiré et celui établit par le pirate. Afin d'éviter une telle situation, contrôlez l'intégrité d'un nouveau serveur SSH en contactant l'administrateur du serveur avant d'établir la première connexion ou dans le cas d'une clé d'hôte sans correspondance valide.

Le protocole SSH est conçu pour fonctionner avec la plupart des types d'algorithme de clé publique ou de format de codage. Après la création de deux valeurs lors de l'échange initial des clés (une valeur de hachage utilisée pour les échanges et une valeur secrète partagée), les deux systèmes commencent immédiatement à calculer de nouveaux algorithmes et de nouvelles clés pour protéger l'authentification et les données qui seront envoyées au cours de la connexion.

Après qu'une certaine quantité de données a été transmise au moyen d'une clé et d'un algorithme précis (la quantité exacte dépend de la mise en application du protocole SSH), un nouvel échange de clés s'effectue et produit un autre ensemble de valeurs de hachage et une autre valeur secrète partagée. De cette façon, même si un pirate réussit à déterminer les valeurs de hachage et la valeur secrète partagée, ces informations ne lui seront utiles que pour une durée limitée.

18.3.2. Authentification

Une fois que la couche transport a créé un tunnel sécurisé pour envoyer les informations entre les deux systèmes, le serveur indique au client les différentes méthodes d'authentification prises en charge, telles que l'utilisation d'une signature dotée d'une clé codée ou la saisie d'un mot de passe. Le client doit ensuite essayer de s'authentifier auprès du serveur au moyen d'une des méthodes spécifiées.

Les serveurs et clients SSH pouvant être configurés de façon à permettre différents types d'authentification, chacune des deux parties se voit attribuer un niveau de contrôle optimal. Le serveur peut décider des méthodes de cryptage à prendre en charge en fonction de son modèle de sécurité et le client peut choisir l'ordre des méthodes d'authentification à utiliser parmi les options disponibles. Grâce à la nature sécurisée de la couche transport SSH, même les méthodes d'authentification qui, au premier abord semblent non-sécurisées, telles que l'authentification basée sur l'hôte et le mot de passe, peuvent être utilisées en toute sécurité.

18.3.3. Canaux

Après avoir effectué avec succès l'authentification au moyen de la couche transport SSH, des canaux multiples sont ouverts au moyen d'une technique appelée multiplexage[1]. Chacun de ces canaux peut ainsi s'occuper de la communication de sessions de terminal différentes d'une part et des sessions de retransmission X11 d'autre part.

Le client et le serveur peuvent tous deux créer un nouveau canal. Chaque canal reçoit ensuite un numéro différent à chaque extrémité de la connexion. Lorsque le client essaie d'ouvrir un nouveau canal, il envoie le numéro du canal accompagné de la requête. Cette information est stockée par le serveur et utilisée pour adresser la communication à ce canal. Cette procédure est utilisée afin que des types différents de session ne créent des nuisances mutuelles et afin que, à la fin d'une session donnée, son canal puisse être fermé sans que la connexion SSH primaire ne soit interrompue.

Les canaux prennent aussi en charge le contrôle du flux de données, ce qui leur permet d'envoyer et de recevoir des données de façon ordonnée. Ce faisant, aucune donnée n'est envoyée par le canal tant que l'hôte n'a pas reçu un message lui indiquant que le canal est ouvert.

Le client et le serveur négocient automatiquement la configuration de chaque canal, selon le type de service demandé par le client et le mode de connexion de l'utilisateur au réseau. Ceci permet de gérer facilement différents types de connexions distantes sans devoir changer l'infrastructure de base du protocole.

Notes

[1]

Une connexion multiplexe se compose de plusieurs signaux envoyés sur un support commun et partagé. Avec le protocole SSH, divers canaux sont envoyés sur une connexion sécurisée commune.