Couches de sécurité SSH
Le protocole SSH permet à tout programme client et serveur créé selon les spécifications du protocole de communiquer de façon sécurisée et d'être utilisé de manière interchangeable.
A l'heure actuelle, il existe deux types différents de protocoles SSH. La version 1 contient de nombreux algorithmes de chiffrement brevetés (toutefois, bon nombre de ces brevets sont périmés) et un trou de sécurité qui donne la possibilité éventuelle d'insérer des données dans le flux de données. La suite OpenSSH des Red Hat Linux 7.3 utilise par défaut la version SSH 2.0, bien qu'elle gère également la version 1. Nous vous conseillons d'utiliser, si possible, des serveurs et clients compatibles avec la version 2.
Les versions 1 et 2 du protocole SSH ajoutent des couches de sécurité qui fournissent leur propre type de protection.
Couche transport
Le rôle principal d'une couche transport est de faciliter une communication sécurisée entre deux ordinateurs hôtes au moment de l'authentification et par la suite également. Elle utilise généralement le protocole TCP/IP et accomplit sa tâche en s'occupant du chiffrement et du déchiffrement des données et en offrant la protection nécessaire aux paquets de données lors de leur envoi et de leur réception. En outre, la couche transport peut également faire la compression des données pour accélérer la vitesse de transfert de l'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 :
l'échange des clés
l'algorithme de clé publique à utiliser
l'algorithme de chiffrement symétrique à utiliser
l'algorithme d'authentification de message à utiliser
l'algorithme repère (hash) à utiliser
Durant l'échange des clés, le serveur s'identifie au client au moyen d'une clé hôte. Evidemment, si le client communique pour la première fois avec ce serveur, la clé du serveur lui est inconnue. OpenSSH contourne ce problème en permettant au client d'accepter la clé hôte du serveur lors de leur première connexion SSH. Ensuite, lors des connexions suivantes, la clé hôte du serveur peut être vérifiée au moyen d'une version enregistrée sur le client, ce qui permet au client de s'assurer qu'il communique bien avec le serveur désiré.
 | Attention |
|---|---|
Un hacker pourrait se faire passer pour le serveur SSH lors de la première connexion car le système local ne reconnaît pas le serveur desiré d'un autre serveur. Afin d'éviter cela, contrôlez l'intégrité d'un nouveau serveur SSH en contactant l'administrateur du serveur avant d'établir la première connexion. |
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 repère 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), il y a à nouveau échange de clés, ce qui produit un autre ensemble de valeurs repère et une autre valeur secrète partagée. De cette façon, même si un hacker réussit à déterminer les valeurs repère et la valeur secrète partagée au départ, il doit refaire l'opération chaque fois qu'un nouvel échange de clés se fait s'il désire continuer d'intercepter la communication.
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 quelles sont les différentes méthodes d'authentification prises en charge, telles que l'utilisation d'une signature chiffrée privée ou l'entrée d'un mot de passe. Le client doit ensuite essayer de s'authentifier au serveur au moyen d'une des méthodes spécifiées.
Etant donné que les serveurs peuvent être configurés de façon à permettre différents types d'authentification, cette méthode donne aux deux parties un niveau de contrôle optimal. Le serveur peut décider quelles méthodes d'authentification 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 celles qui sont disponibles. Grâce à la nature sécurisée de la couche transport SSH, même les méthodes d'authentification qui, de prime abord, semblent non sécurisées, telles que l'authentification d'ordinateur hôte, peuvent être utilisées en toute sécurité.
La plupart des utilisateurs exigeant un shell sécurisé procèdent à l'authentification au moyen d'un mot de passe. Comme ce mot de passe est complètement chiffré, il peut être envoyé sans problème sur n'importe quel réseau.
Connexion
Après avoir effectué avec succès l'authentification au moyen de la couche transport SSH, des canaux multiples sont ouverts en transformant la connexion simple entre les deux systèmes en connexion multiplex[1]. Chaque canal peut ainsi s'occuper de la communication d'une session de terminal différente, du transfert d'informations X11 ou de tout autre service séparé essayant d'utiliser la connexion SSH.
Le client et le serveur peuvent tous deux créer un nouveau canal et chaque canal reçoit un numéro différent aux deux extrémités de la connexion. Lorsque le client essaye d'ouvrir un nouveau canal, les clients envoient 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. Ainsi, des types différents de session ne peuvent se nuire entre eux et, lorsqu'une session se termine, son canal peut être fermé sans que la connexion SSH primaire ne s'interrompe.
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.