Comprendre Secure Shell Packet Exchange

Introduction

Ce document décrit l'échange au niveau paquet pendant la négociation Secure Shell (SSH).

Conditions préalables

Exigences

Cisco recommande que vous ayez une connaissance des concepts de sécurité de base :

• Authentification
• Confidentialité
• Intégrité
• Méthodes d'échange de clés

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Protocole SSH

Le protocole SSH est une méthode de connexion à distance sécurisée d'un ordinateur à un autre. Les applications SSH sont basées sur une architecture client-serveur, connectant une instance de client SSH à un serveur SSH.

Échange SSH

1. La première étape de SSH est appelée Identification String Exchange.

 1.1. Le client construit un paquet et l’envoie au serveur contenant :

•  Version du protocole SSH
•  Version du logiciel

Version du protocole client et version du logiciel

1.2. Le serveur répond avec son propre échange de chaîne d’identification, y compris sa version de protocole SSH et sa version logicielle.

Version du protocole serveur et version du logiciel

2. Étape suivante  Algorithm Negotiation. Dans cette étape, le client et le serveur négocient les algorithmes suivants :

• Échange De Clés
• Chiffrement
• HMAC (Message Authentication Code) basé sur le hachage
• Compression

2.1. Le client envoie un message Key Exchange Init au serveur, en spécifiant les algorithmes pris en charge. Les algorithmes sont répertoriés par ordre de préférence.

Init d'échange de clés client

Algorithmes pris en charge par le client

2.2. Le serveur répond avec son propre message Key Exchange Init, en répertoriant les algorithmes qu’il prend en charge.

2.3. Étant donné que ces messages sont échangés simultanément, les deux parties comparent leurs listes d’algorithmes. S'il existe une correspondance dans les algorithmes pris en charge par les deux côtés, ils passent à l'étape suivante. S'il n'y a pas de correspondance exacte, le serveur sélectionne le premier algorithme de la liste du client qu'il prend également en charge.

Remarque : Si le client et le serveur ne parviennent pas à s'entendre sur un algorithme commun, l'échange de clés échoue.

Init Exchange de clé serveur

3. Ensuite, les deux parties entrent dans la Key Exchange phase de génération du secret partagé à l’aide de l’échange de clés DH et authentifient le serveur :

3.1. Le client génère une paire de clés, Public and Private, puis envoie la clé publique DH dans le paquet Diffie-Hellman Group Exchange Init. Cette paire de clés est utilisée pour le calcul des clés secrètes.

Client Diffie-Hellman Group Exchange Init

3.2. Le serveur génère sa propre paire de Public and Private kclés. Il utilise la clé publique du client et sa propre paire de clés pour calculer le secret partagé.

3.3. Le serveur calcule également un hachage Exchange avec les entrées suivantes :

• Chaîne D'Identification Du Client
• Chaîne D'Identification Du Serveur
• Charge utile de l'initialisation d'échange de clés client 
• Charge utile de l'initialisation d'échange de clés serveur 
• Clé publique de serveur à partir des clés d'hôte (paire de clés RSA)
• Clé publique DH du client
• Clé publique DH du serveur
• Clé secrète partagée

3.4. Après avoir calculé le hachage, le serveur le signe avec sa clé privée RSA.

3.5. Le serveur construit un message Diffie-Hellman Group Exchange qui inclut :

•  Clé publique RSA du serveur (pour aider le client à authentifier le serveur)
•  DH Clé publique du serveur (pour calculer le secret partagé)
•  HASH (pour authentifier le serveur et prouver que le serveur a généré le secret partagé, car la clé secrète fait partie du calcul de hachage)

Réponse de Server Diffie-Hellman Group Exchange

3.6. Après avoir reçu la réponse Diffie-Hellman Group Exchange, le client calcule le hachage de la même manière et le compare au hachage reçu, en le décryptant à l’aide de la clé publique RSA du serveur.

3.7. Avant de déchiffrer le HASH reçu, le client doit vérifier la clé publique du serveur. Cette vérification s'effectue au moyen d'un certificat numérique signé par une autorité de certification (AC). Si le certificat n'existe pas, c'est au client de décider d'accepter ou non la clé publique du serveur.

Remarque : lorsque vous utilisez SSH pour vous connecter à un périphérique qui n'utilise pas de certificat numérique pour la première fois, vous pouvez rencontrer une fenêtre contextuelle vous demandant d'accepter manuellement la clé publique du serveur. Pour éviter de voir cette fenêtre contextuelle chaque fois que vous vous connectez, vous pouvez choisir d'ajouter la clé d'hôte du serveur à votre cache.

Clé publique du serveur

4. Puisque le secret partagé est maintenant généré, les deux extrémités l'utilisent pour dériver ces clés :

•  Clés de chiffrement
•  IV Keys (Clés IV) : nombres aléatoires utilisés comme entrée dans des algorithmes symétriques pour améliorer la sécurité.
•  Clés d'intégrité

La fin de l'échange de clés est signalée par l'échange du NEW KEYS message, qui informe chaque partie que tous les messages futurs sont chiffrés et protégés à l'aide de ces nouvelles clés.

Nouvelles clés client et serveur

5. La dernière étape est la demande de service. Le client envoie un paquet de demande de service SSH au serveur pour lancer l'authentification de l'utilisateur. Le serveur répond avec un message d'acceptation de service SSH, invitant le client à se connecter. Cet échange se produit sur le canal sécurisé établi.

Informations connexes

• Configurer SSH sur les routeurs et les commutateurs
• Protocole SSH (Secure Shell) de la couche transport
• Assistance technique de Cisco et téléchargements