TOC

Comprendre le processus de cryptage et de connexion SSH

introduction

SSH, ou shell sécurisé, est un protocole sécurisé et le moyen le plus courant d’administrer en toute sécurité des serveurs distants. En utilisant un certain nombre de technologies de cryptage, SSH fournit un mécanisme permettant d’établir une connexion sécurisée par cryptographie entre deux parties, d’authentifier chaque côté, et de transmettre des commandes et des sorties.

Dans d'autres guides, nous avons discuté dehow to configure SSH key-based access,how to connect using SSH etsome SSH tips and tricks.

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

Chiffrement symétrique, chiffrement asymétrique et hachages

Afin de sécuriser la transmission des informations, SSH utilise un certain nombre de types différents de techniques de manipulation de données à différents moments de la transaction. Celles-ci incluent des formes de chiffrement symétrique, de chiffrement 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 dans lequel une clé peut être utilisée pour chiffrer des messages destinés à la partie adverse et pour déchiffrer les messages reçus de l'autre participant. Cela signifie que toute personne qui détient la clé peut chiffrer et déchiffrer des messages destinés à toute autre personne détenant la clé.

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

SSH utilise les clés symétriques pour chiffrer la totalité de la connexion. Contrairement à ce que certains utilisateurs supposent, les paires de clés asymétriques publiques / privées pouvant être créées ne sont utilisées que pour l’authentification, pas pour le cryptage de la connexion. Le chiffrement symétrique permet de protéger même l’authentification du mot de passe contre l’espionnage.

Le client et le serveur contribuent tous deux à l'établissement de cette clé, et le secret qui en résulte n'est jamais connu de tiers. La clé secrète est créée via un processus appelé algorithme d'échange de clé. Cet échange a pour résultat que le serveur et le client parviennent tous deux à la même clé indépendamment en partageant certaines données publiques et en les manipulant avec certaines données secrètes. Ce processus est expliqué plus en détail ultérieurement.

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 que cela est établi, le reste des données doit être crypté avec ce secret partagé. Ceci est fait avant d'authentifier un client.

SSH peut être configuré pour utiliser divers systèmes de chiffrement symétriques, notamment AES, Blowfish, 3DES, CAST128 et Arcfour. Le serveur et le client peuvent tous deux choisir une liste de leurs chiffrements pris en charge, classés par préférence. La première option disponible sur le serveur dans la liste du client est utilisée comme algorithme de chiffrement dans les deux sens.

Sur Ubuntu 14.04, le client et le serveur sont configurés par défaut comme ceci:aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected] ,[email protected],[email protected],aes128-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour.

Cela signifie que si deux machines Ubuntu 14.04 se connectent l'une à l'autre (sans remplacer les chiffrements par défaut via les options de configuration), elles utiliseront toujours le chiffrementaes128-ctr pour chiffrer leur connexion.

Chiffrement asymétrique

Le cryptage asymétrique est différent du cryptage symétrique en ce que pour envoyer des données dans une seule direction, deux clés associées sont nécessaires. L'une de ces clés est connue sous le nom deprivate key, tandis que l'autre est appeléepublic key.

La clé publique peut être librement partagée avec n'importe quelle partie. Il est associé à sa clé jumelée, mais la clé privéecannot est 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 peut envoyer.

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

SSH utilise le cryptage asymétrique à plusieurs endroits. Pendant le processus d'échange de clé initial utilisé pourset up le cryptage symétrique (utilisé pour crypter la session), un cryptage asymétrique est utilisé. À ce stade, 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 plus discutée du cryptage asymétrique avec SSH provient de l’authentification basée sur la clé SSH. Les paires de clés SSH peuvent être utilisées pour authentifier un client sur un serveur. Le client crée une paire de clés puis la télécharge sur tout serveur distant auquel il souhaite accéder. Il est placé dans un fichier appeléauthorized_keys dans le répertoire~/.ssh dans le répertoire de base du compte utilisateur sur le serveur distant.

Une fois le chiffrement symétrique établi pour sécuriser les communications entre le serveur et le client, le client doit s'authentifier pour pouvoir accéder. Le serveur peut utiliser la clé publique de ce fichier pour chiffrer un message d’interrogation au client. Si le client peut prouver qu'il a été capable de déchiffrer ce message, il a démontré qu'il possède la clé privée associée. Le serveur peut alors configurer l'environnement pour le client.

Hachage

Une autre forme de manipulation de données dont SSH tire parti est le hachage cryptographique. Les fonctions de hachage cryptographiques sont des méthodes permettant de créer une "signature" succincte ou un résumé d'un ensemble d'informations. Leurs principales caractéristiques sont qu’ils ne doivent jamais être inversés, qu’ils sont pratiquement impossibles à influencer de manière prévisible et qu’ils sont pratiquement uniques.

L'utilisation de la même fonction de hachage et du même message devrait produire le même hachage; la modification d'une partie des données doit produire un hachage entièrement différent. Un utilisateur devraitnot être capable de produire le message original à partir d'un hachage donné, mais ilshould être capable 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 de vérification de l'authenticité de la communication. La principale utilisation de SSH est HMAC, ou des codes d’authentification de message basés sur un hachage. Ceux-ci 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 ci-dessus, un algorithme de code d'authentification de message (MAC) est sélectionné. L’algorithme est choisi en consultant la liste des choix de MAC acceptables du client. Le premier de cette liste pris en charge par le serveur sera utilisé.

Chaque message envoyé après la négociation du cryptage 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 et du contenu du message.

Le MAC lui-même est envoyé en dehors 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 de chiffrement préalable des données, puis de calcul du MAC.

Comment fonctionne 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 les connexions sur un port désigné. Il est responsable de la négociation de la connexion sécurisée, de l'authentification de la partie qui se connecte et de la création de l'environnement approprié si les informations d'identification sont acceptées.

Il incombe au client d’entamer la négociation TCP initiale 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 les informations d’identification à authentifier.

Une session SSH est établie en deux étapes distinctes. Le premier consiste à convenir d'un cryptage et à le mettre en place afin de protéger les communications futures. La deuxième étape consiste à authentifier l'utilisateur et à déterminer si l'accès au serveur doit être accordé.

Négociation du cryptage 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é d’hôte publique, que le client peut utiliser pour vérifier s’il s’agissait bien de l’hôte prévu.

À ce stade, les deux parties négocient une clé de session à l'aide d'une version de ce que l'on appelle l'algorithme Diffie-Hellman. Cet algorithme (et ses variantes) permettent à chaque partie de combiner ses propres données privées avec des données publiques de l'autre système pour aboutir à une clé de session secrète identique.

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

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

  1. Les deux parties conviennent d’un nombre premier élevé qui servira de valeur de départ.

  2. Les deux parties conviennent d'un générateur de chiffrement (généralement AES), qui sera utilisé pour manipuler les valeurs d'une manière prédéfinie.

  3. Indépendamment, chaque partie présente un autre nombre premier qui est gardé secret de l'autre partie. Ce numéro est utilisé comme clé privée pour cette interaction (différent de la clé privée SSH utilisée pour l'authentification).

  4. La clé privée générée, le générateur de cryptage et le nombre premier partagé sont utilisés pour générer une clé publique dérivée de la clé privée, mais pouvant être partagée avec l'autre partie.

  5. Les deux participants échangent ensuite leurs clés publiques générées.

  6. L’entité réceptrice utilise sa propre clé privée, la clé publique de l’autre partie et le nombre premier partagé initial 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, il en résultera la clé secrète partagée desame.

  7. Le secret partagé est ensuite utilisé pour chiffrer toutes les communications qui suivent.

Le cryptage secret partagé utilisé pour le reste de la connexion est appelé protocole de paquet binaire. Le processus ci-dessus permet à chaque partie de participer de manière égale à 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 sur des canaux non sécurisés.

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 cette opération est d’envelopper toutes les communications ultérieures dans un tunnel crypté qui ne peut pas être déchiffré par des tiers.

Une fois le cryptage de session établi, l'étape d'authentification de l'utilisateur commence.

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

L'étape suivante consiste à authentifier l'utilisateur et à décider de l'accès. Différentes méthodes peuvent être utilisées pour l'authentification, en fonction de ce que le serveur accepte.

Le plus simple est probablement l'authentification par mot de passe, dans laquelle le serveur demande simplement au client le mot de passe du compte auquel il tente de se connecter. Le mot de passe est envoyé via le cryptage négocié, il est donc sécurisé des tiers.

Bien que le mot de passe soit crypté, cette méthode n'est généralement pas recommandée en raison des limitations relatives à la complexité du mot de passe. Les scripts automatisés peuvent casser très facilement les mots de passe de longueur normale par rapport aux 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 la clé privée, il n'existe aucune méthode permettant de dériver la clé privée 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 dernière section. La procédure se passe comme ça:

  1. Le client commence par envoyer un identifiant pour la paire de clés avec laquelle il souhaite s'authentifier au serveur.

  2. Le serveur vérifie le fichierauthorized_keys du compte auquel le client tente de se connecter pour l’ID de clé.

  3. Si une clé publique avec l'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 numéro.

  4. Le serveur envoie ce message crypté au client.

  5. Si le client a réellement la clé privée associée, il pourra déchiffrer le message à l'aide de cette clé, révélant ainsi le numéro d'origine.

  6. Le client combine le numéro déchiffré avec la clé de session partagée utilisée pour chiffrer la communication et calcule le hachage MD5 de cette valeur.

  7. Le client renvoie ensuite ce hachage MD5 au serveur en tant que réponse au message du numéro chiffré.

  8. Le serveur utilise la même clé de session partagée et le numéro d'origine qu'il a envoyé au client pour calculer la valeur MD5 par ses propres moyens. 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é.

Comme vous pouvez le constater, l’asymétrie des clés permet au serveur de chiffrer les messages adressés au client à l’aide de la clé publique. Le client peut ensuite prouver qu'il détient la clé privée en déchiffrant le message correctement. Les deux types de chiffrement utilisés (secret partagé symétrique et clés publique / privée asymétriques) peuvent chacun exploiter leurs atouts spécifiques dans ce modèle.

Conclusion

En savoir plus sur les étapes de la négociation de 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. J'espère que vous avez maintenant une meilleure idée de la relation entre divers composants et algorithmes et que vous comprenez comment toutes ces pièces s'emboîtent.

Related