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.