Compréhension du processus de chiffrement et de connexion SSH

Tutoriels

Introduction

SSH, ou Secure Shell, est un protocole sécurisé et le moyen le plus courant d’administrer en toute sécurité des serveurs à distance. En utilisant plusieurs technologies de cryptage, SSH fournit un mécanisme pour établir une connexion cryptographiquement sécurisée entre deux parties, authentifier chaque côté auprès de l’autre, et échanger des commandes et des résultats.

Dans ce guide, nous examinerons les techniques de cryptage sous-jacentes que SSH utilise et les méthodes qu’il utilise pour établir des connexions sécurisées. Ces informations peuvent être utiles pour comprendre les différentes couches de cryptage et les différentes étapes nécessaires pour former une connexion et authentifier les deux parties.

Compréhension du cryptage symétrique, du cryptage asymétrique et des hachages

Pour sécuriser la transmission d’informations, SSH emploie plusieurs types différents de techniques de manipulation de données à divers points de la transaction. Celles-ci comprennent des formes de cryptage symétrique, de cryptage asymétrique et de hachage.

Chiffrement symétrique

La relation entre les composants qui chiffrent et déchiffrent les données détermine si un schéma de chiffrement est symétrique ou asymétrique.

Le chiffrement symétrique est un type de chiffrement où une clé peut être utilisée pour chiffrer des messages à destination de l’autre partie, et également pour déchiffrer les messages reçus de l’autre participant. Cela signifie que quiconque possède la clé peut chiffrer et déchiffrer des messages pour toute autre personne détenant la clé.

Ce type de schéma de chiffrement est souvent appelé chiffrement à « secret partagé » ou chiffrement à « clé secrète ». Il y a généralement une seule clé qui est utilisée pour toutes les opérations ou une paire de clés où la relation est découvrable et il est trivial de dériver la clé opposée.

Les clés symétriques sont utilisées par SSH pour chiffrer l’ensemble de la connexion. Contrairement à ce que certains utilisateurs supposent, les paires de clés asymétriques public/privé qui peuvent être créées ne sont utilisées que pour l’authentification, pas pour le chiffrement de la connexion. Le chiffrement symétrique permet même que l’authentification par mot de passe soit protégée contre l’espionnage.

Le client et le serveur contribuent tous deux à l’établissement de cette clé, et le secret résultant n’est jamais connu des parties extérieures. La clé secrète est créée à travers un processus connu sous le nom d’algorithme d’échange de clés. Cet échange résulte en ce que le serveur et le client arrivent tous deux à la même clé de manière indépendante en partageant certaines données publiques et en les manipulant avec certaines données secrètes. Ce processus est expliqué plus en détail plus tard.

La clé de chiffrement symétrique créée par cette procédure est basée sur la session et constitue le chiffrement réel des données envoyées entre le serveur et le client. Une fois cela établi, le reste des données doit être chiffré avec ce secret partagé. Cela est fait avant d’authentifier un client.

SSH peut être configuré pour utiliser une variété de systèmes de chiffrement symétrique différents, y compris Advanced Encryption Standard (AES), Blowfish, 3DES, CAST128 et Arcfour. Le serveur et le client peuvent tous deux décider d’une liste de leurs chiffres supportés, ordonnés par préférence. La première option de la liste du client qui est disponible sur le serveur est utilisée comme algorithme de chiffrement dans les deux sens.

Sur Ubuntu 20.04, tant le client que le serveur sont configurés par défaut comme suit :

Cela signifie que si deux machines Ubuntu 20.04 se connectent entre elles (sans remplacer les chiffrements par défaut via les options de configuration), elles utiliseront toujours par défaut le chiffrement [email protected] pour crypter leur connexion.

Chiffrement asymétrique

Le chiffrement asymétrique est différent du chiffrement symétrique car pour envoyer des données dans une seule direction, deux clés associées sont nécessaires. L’une de ces clés est appelée clé privée, tandis que l’autre est appelée clé publique.

La clé publique peut être partagée librement avec n’importe quelle partie. Elle est associée à sa clé appariée, mais la clé privée ne peut pas être dérivée de la clé publique. La relation mathématique entre la clé publique et la clé privée permet à la clé publique de chiffrer des messages qui ne peuvent être déchiffrés que par la clé privée. Il s’agit d’une capacité à sens unique, ce qui signifie que la clé publique n’a pas la capacité de déchiffrer les messages qu’elle écrit, ni de déchiffrer quoi que ce soit que la clé privée pourrait lui envoyer.

La clé privée doit être gardée entièrement secrète et ne doit jamais être partagée avec une autre partie. C’est une exigence clé pour que le paradigme de la clé publique fonctionne. La clé privée est le seul composant capable de déchiffrer les messages qui ont été chiffrés à l’aide de la clé publique associée. En vertu de ce fait, toute entité capable de déchiffrer ces messages a démontré qu’elle contrôle la clé privée.

SSH utilise le cryptage asymétrique à plusieurs endroits différents. Pendant le processus initial d’échange de clés utilisé pour configurer le cryptage symétrique (utilisé pour chiffrer la session), le cryptage asymétrique est utilisé. À cette étape, les deux parties produisent des paires de clés temporaires et échangent la clé publique afin de produire le secret partagé qui sera utilisé pour le cryptage symétrique.

L’utilisation la plus discutée du cryptage asymétrique avec SSH provient de l’authentification basée sur les clés SSH. Les paires de clés SSH peuvent être utilisées pour authentifier un client auprès d’un serveur. Le client crée une paire de clés puis télécharge la clé publique vers n’importe quel serveur distant auquel il souhaite accéder. Celle-ci est placée dans un fichier appelé authorized_keys dans le répertoire ~/.ssh du répertoire personnel du compte utilisateur sur le serveur distant.

Après que le cryptage symétrique est établi pour sécuriser les communications entre le serveur et le client, le client doit s’authentifier pour être autorisé à accéder. Le serveur peut utiliser la clé publique dans ce fichier pour chiffrer un message de défi au client. Si le client peut prouver qu’il a pu déchiffrer ce message, il a démontré qu’il possède la clé privée associée. Ensuite, le serveur peut configurer l’environnement pour le client.

Hashage

Une autre forme de manipulation de données dont SSH tire parti est le hachage cryptographique. Les fonctions de hachage cryptographique sont des méthodes de création d’une « signature » succincte ou d’un résumé d’un ensemble d’informations. Leurs principaux attributs distinctifs sont qu’ils ne sont jamais censés être inversés, qu’ils sont pratiquement impossibles à influencer de manière prévisible et qu’ils sont pratiquement uniques.

En utilisant la même fonction de hachage et le même message, on devrait obtenir le même hachage ; modifier une partie des données devrait produire un hachage entièrement différent. Un utilisateur ne devrait pas être en mesure de produire le message d’origine à partir d’un hachage donné, mais il devrait être en mesure de dire si un message donné a produit un hachage donné.

Compte tenu de ces propriétés, les hachages sont principalement utilisés à des fins d’intégrité des données et pour vérifier l’authenticité de la communication. L’utilisation principale dans SSH se fait avec HMAC, ou codes d’authentification de message basés sur le hachage. Ils sont utilisés pour s’assurer que le texte du message reçu est intact et non modifié.

Dans le cadre de la négociation de chiffrement symétrique décrite précédemment, un algorithme de code d’authentification de message (MAC) est sélectionné. L’algorithme est choisi en parcourant la liste des choix de MAC acceptables du client. Le premier de cette liste que le serveur prend en charge sera utilisé.

Chaque message envoyé après la négociation du chiffrement doit contenir un MAC afin que l’autre partie puisse vérifier l’intégrité du paquet. Le MAC est calculé à partir du secret partagé symétrique, du numéro de séquence du paquet du message et du contenu réel du message.

Le MAC lui-même est envoyé à l’extérieur de la zone chiffrée de manière symétrique en tant que dernière partie du paquet. Les chercheurs recommandent généralement cette méthode consistant à d’abord chiffrer les données, puis à calculer le MAC.

Comprendre le fonctionnement de SSH

Vous avez probablement déjà une compréhension de base du fonctionnement de SSH. Le protocole SSH utilise un modèle client-serveur pour authentifier deux parties et chiffrer les données entre elles.

Le composant serveur écoute sur un port désigné pour les connexions. Il est responsable de négocier la connexion sécurisée, d’authentifier la partie connectée et de créer l’environnement correct si les informations d’identification sont acceptées.

Le client est responsable de commencer la poignée de main initiale du protocole de contrôle de transmission (TCP) avec le serveur, de négocier la connexion sécurisée, de vérifier que l’identité du serveur correspond aux informations précédemment enregistrées et de fournir des informations d’identification pour l’authentification.

Une session SSH est établie en deux étapes distinctes. La première consiste à convenir et à établir un chiffrement pour protéger les futures communications. La deuxième étape consiste à authentifier l’utilisateur et à découvrir si l’accès au serveur doit être accordé.

Négociation du chiffrement pour la session

Lorsqu’une connexion TCP est établie par un client, le serveur répond avec les versions de protocole qu’il prend en charge. Si le client peut correspondre à l’une des versions de protocole acceptables, la connexion se poursuit. Le serveur fournit également sa clé hôte publique, que le client peut utiliser pour vérifier si c’était le serveur prévu.

À ce stade, les deux parties négocient une clé de session en utilisant une version de quelque chose appelé l’algorithme de Diffie-Hellman. Cet algorithme (et ses variantes) permettent à chaque partie de combiner ses propres données privées avec les données publiques de l’autre système pour arriver à une clé de session secrète identique.

La clé de session sera utilisée pour chiffrer l’ensemble de la session. Les paires de clés publiques et privées utilisées pour cette partie de la procédure sont complètement séparées des clés SSH utilisées pour authentifier un client auprès du serveur.

La base de cette procédure pour le Diffie-Hellman classique est la suivante :

  • Les deux parties s’accordent sur un grand nombre premier, qui servira de valeur de départ.
  • Les deux parties s’accordent sur un générateur de chiffrement (généralement AES), qui sera utilisé pour manipuler les valeurs de manière prédéfinie.
  • Indépendamment, chaque partie trouve un autre nombre premier qui est gardé secret de l’autre partie. Ce nombre est utilisé comme clé privée pour cette interaction (différente de la clé SSH privée utilisée pour l’authentification).
  • La clé privée générée, le générateur de chiffrement et le nombre premier partagé sont utilisés pour générer une clé publique qui est dérivée de la clé privée, mais qui peut être partagée avec l’autre partie.
  • Les deux participants échangent ensuite leurs clés publiques générées.
  • L’entité réceptrice utilise sa propre clé privée, la clé publique de l’autre partie et le nombre premier partagé d’origine pour calculer une clé secrète partagée. Bien que cela soit calculé indépendamment par chaque partie, en utilisant des clés privées et publiques opposées, cela entraînera la même clé secrète partagée.
  • Le secret partagé est ensuite utilisé pour chiffrer toutes les communications qui suivent.

Ce processus permet à chaque partie de participer également à la génération du secret partagé, ce qui ne permet pas à une extrémité de contrôler le secret. Il accomplit également la tâche de générer un secret partagé identique sans jamais avoir à envoyer cette information via des canaux non sécurisés. Le chiffrement de secret partagé utilisé pour le reste de la connexion est appelé protocole de paquet binaire.

Le secret généré est une clé symétrique, ce qui signifie que la même clé utilisée pour chiffrer un message peut être utilisée pour le déchiffrer de l’autre côté. Le but de ceci est d’envelopper toutes les communications ultérieures dans un tunnel chiffré qui ne peut pas être déchiffré par des tiers.

Après que le chiffrement de session soit établi, commence l’étape d’authentification de l’utilisateur.

Authentification de l’accès de l’utilisateur au serveur

La prochaine étape consiste à authentifier l’utilisateur et à décider de l’accès. Il existe plusieurs méthodes qui peuvent être utilisées pour l’authentification, en fonction de ce que le serveur accepte.

La méthode générale est l’authentification par mot de passe, où le serveur demande au client le mot de passe du compte avec lequel il tente de se connecter. Le mot de passe est envoyé via le chiffrement négocié, il est donc sécurisé contre les tiers.

Même si le mot de passe est crypté, cette méthode n’est généralement pas recommandée en raison des limitations sur la complexité du mot de passe. Les scripts automatisés peuvent facilement casser les mots de passe de longueurs normales par rapport à d’autres méthodes d’authentification.

L’alternative la plus populaire et recommandée est l’utilisation de paires de clés SSH. Les paires de clés SSH sont des clés asymétriques, ce qui signifie que les deux clés associées remplissent des fonctions différentes.

La clé publique est utilisée pour chiffrer des données qui ne peuvent être déchiffrées qu’avec la clé privée. La clé publique peut être librement partagée, car, bien qu’elle puisse chiffrer pour la clé privée, il n’existe aucune méthode pour dériver la clé privée à partir de la clé publique.

L’authentification à l’aide de paires de clés SSH commence après que le chiffrement symétrique a été établi comme décrit dans la section précédente. La procédure se déroule comme suit:

  • Le client commence par envoyer un ID pour la paire de clés avec laquelle il souhaite s’authentifier au serveur.
  • Le serveur vérifie le fichier authorized_keys du compte auquel le client tente de se connecter pour trouver l’ID de la clé.
  • Si une clé publique avec un ID correspondant est trouvée dans le fichier, le serveur génère un nombre aléatoire et utilise la clé publique pour chiffrer le nombre.
  • Le serveur envoie ce message chiffré au client.
  • Si le client possède effectivement la clé privée associée, il pourra décrypter le message à l’aide de cette clé, révélant ainsi le nombre d’origine.
  • Le client combine le nombre décrypté avec la clé de session partagée qui est utilisée pour chiffrer la communication, et calcule le hachage MD5 de cette valeur. MD5 est un algorithme de hachage qui utilise la fonction de hachage pour générer une valeur de hachage de 128 bits.
  • Le client envoie ensuite ce hachage MD5 au serveur en réponse au message chiffré contenant le nombre.
  • Le serveur utilise la même clé de session partagée et le nombre d’origine qu’il a envoyé au client pour calculer la valeur MD5 de son côté. Il compare son propre calcul à celui que le client a renvoyé. Si ces deux valeurs correspondent, cela prouve que le client était en possession de la clé privée et que le client est authentifié.

En somme, l’asymétrie des clés permet au serveur de chiffrer les messages destinés au client en utilisant la clé publique. Le client peut alors prouver qu’il détient la clé privée en déchiffrant correctement le message. Les deux types de chiffrement utilisés (secret partagé symétrique et clés publiques/privées asymétriques) peuvent chacun exploiter leurs forces spécifiques dans ce modèle.

Conclusion

Apprendre les étapes de négociation de la connexion et les couches de chiffrement utilisées dans SSH peut vous aider à mieux comprendre ce qui se passe lorsque vous vous connectez à un serveur distant. Vous pouvez maintenant reconnaître la relation entre divers composants et algorithmes, et comprendre comment toutes ces pièces s’emboîtent. Pour en savoir plus sur SSH, consultez les guides suivants :

Source:
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process