20.3. Séquence d'événements d'une connexion SSH

20.3.1. Couche de transport

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

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

• Des clés sont échangées.

• L'algorithme de cryptage de clés publiques est déterminé.

• L'algorithme de cryptage symétrique est déterminé.

• L'algorithme d'authentification de message est déterminé.

• L'algorithme de hachage est déterminé.

Lors de l'échange des clés, le serveur s'identifie au client au moyen d'une clé d'hôte unique. Si le client communique pour la première fois avec ce serveur, la clé du serveur n'est pas connue du client et la connexion ne peut pas ê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 est vérifiée en la comparant avec 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 ne correspond plus à la version enregistrée sur le client, l'utilisateur doit supprimer cette dernière avant qu'une nouvelle connexion puisse avoir lieu.

Attention

Il est tout à fait possible pour un pirate de se faire passer pour le serveur SSH lors de la première connexion car le système local ne détecte aucune différence entre le serveur désiré et le faux serveur créé 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 où une clé d'hôte ne correspond pas à celle stockée sur le serveur.

Le protocole SSH est conçu pour fonctionner avec presque tout d'algorithme de clé publique ou tout format de codage. Après que l'échange initial des clés crée 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 futures données envoyées via la connexion.

Après la transmission d'une certaine quantité de données au moyen d'une clé et d'un algorithme précis (la quantité exacte dépend de l'implémentation du protocole SSH), un nouvel échange de clés s'effectue ; cette opération engendre la création d'un autre ensemble de valeurs de hachage et d'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.

20.3.2. Authentification

Une fois que la couche de 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 pouvent être configurés de façon à permettre différents types d'authentification, donnant à chacune des deux parties un niveau de contrôle optimal. Le serveur peut décider des méthodes de cryptage qu'il prend en charge en fonction de son modèle de sécurité et le client lui peut choisir l'ordre des méthodes d'authentification à utiliser parmi les options disponibles. Grâce à la nature sécurisée de la couche de 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é.

20.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 traiter la communication pour des sessions de terminal différentes et pour des sessions de retransmission X11.

Le client et le serveur peuvent 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. Ces informations sont stockées par le serveur et utilisées pour diriger la communication vers ce canal. Cette procédure est utilisée afin que des types différents de session ne créent pas de nuisances mutuelles et de sorte qu'à 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 sur 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, en fonction du type de service demandé par le client et de la manière selon laquelle l'utilisateur est connecté au réseau. Ainsi, le traitement des différents types de connexions distantes est non seulement extrêmement flexible, mais il ne nécessite même pas d'apporter des modifications à la structure de base du protocole.