Protocole Secure Shell (SSH)

Secure Shell est un protocole sécurisé et le moyen le plus courant d'administrer en toute sécurité des serveurs distants.

Il utilise un certain nombre de technologies de cryptage. SSH fournit un mécanisme pour établir une connexion cryptographiquement sécurisée entre deux parties, authentifiant chaque côté à l'autre et en passant des commandes et des sorties dans les deux sens. SSH est organisé en trois protocoles qui s'exécutent généralement sur TCP, comme dans la figure ci-dessous.

•  Protocole de couche de transport : il assure la confidentialité des données, l'authentification du serveur et l'intégrité des données avec une confidentialité de transmission. La couche de transport peut éventuellement fournir une compression.
•  Protocole d'authentification utilisateur : il authentifie l'utilisateur auprès du serveur.
•  Protocole de connexion : multiplexe plusieurs canaux de communication logiques sur une seule connexion SSH sous-jacente.

La couche de transport fournit une authentification sécurisée basée sur le traitement par le serveur d'une paire de clés publique-privée. Un serveur peut avoir plusieurs clés d'hôte utilisant plusieurs algorithmes de chiffrement asymétriques différents. Plusieurs hôtes peuvent partager la même clé d'hôte. Dans tous les cas, la clé hôte du serveur est utilisée lors de l'échange de clé pour authentifier l'identité de l'hôte. Pour que cette authentification soit possible, le client doit avoir une connaissance présomptive de la clé publique de l'hôte du serveur. La figure ci-dessous illustre la séquence d'événements dans le protocole de la couche de transport SSH.

1. Le client établit une connexion TCP au serveur avec le protocole TCP et ne fait pas partie du protocole de la couche transport.
2. A l'établissement de la connexion, le serveur client échange des données appelées paquets dans le champ de données du segment TCP.

Le format de l'échange de paquets entre le client et le serveur est donné dans la figure ci-dessous.

•  pktl : C'est la longueur du paquet en octets. Cela n'inclut pas la longueur du paquet et le champ MAC du message (code d'authentification du message).
•  pdl : la longueur de remplissage est la longueur du champ de remplissage aléatoire.
•  Charge utile : Il constitue l'utilisation du contenu du paquet. Cette partie est compressée avant la négociation de l'algorithme. Si la compression est négociable, alors dans les paquets suivants, ce champ est compressé.
•  Remplissage : ce champ est ajouté après la négociation d'un algorithme de chiffrement. Il contient des octets de remplissage aléatoires de sorte que la longueur totale du paquet (à l'exclusion du champ MAC) soit un multiple de la taille du bloc de chiffrement, ou 8 octets pour un chiffrement de flux.
•  Code d'authentification de message (MAC) : si l'authentification de message a été négociée, ce champ contient la valeur MAC. La valeur MAC est calculée sur l'ensemble du paquet plus un numéro de séquence, à l'exclusion du champ MAC. Le numéro de séquence est une séquence de paquets implicite de 32 bits qui est initialisée à zéro pour le premier paquet et incrémentée pour chaque paquet. Le numéro de séquence n'est pas inclus dans le paquet envoyé via la connexion TCP.

Une fois qu'un client SSH contacte un serveur, des informations clés sont échangées afin que les deux systèmes puissent correctement construire la couche de transport. Les étapes suivantes se produisent lors de cet échange :

•  Les clés sont échangées
•  L'algorithme de chiffrement à clé publique est déterminé
•  L'algorithme de chiffrement symétrique est déterminé
•  L'algorithme d'authentification du message est déterminé
•  L'algorithme de hachage est déterminé

Lors de l'échange de clés, le serveur s'identifie auprès du client avec une clé d'hôte unique. Si le client n'a jamais communiqué avec ce serveur particulier auparavant, la clé d'hôte du serveur est inconnue du client et il ne se connecte pas. SSH contourne ce problème en acceptant la clé d'hôte du serveur. Cela se fait après que l'utilisateur a été notifié et a à la fois accepté et vérifié la nouvelle clé d'hôte. Lors des connexions suivantes, la clé d'hôte du serveur est comparée à la version enregistrée sur le client, ce qui garantit que le client communique bien avec le serveur prévu. Si, à l'avenir, la clé d'hôte ne correspond plus, l'utilisateur doit supprimer la version enregistrée du client avant qu'une connexion puisse se produire.

Il authentifie le client auprès du serveur. Le protocole d'authentification de l'utilisateur utilise toujours trois types de messages. Le format d'une demande d'authentification du client est le suivant :

Byte SSH-MSG_USERAUTGH_REQUEST (50)
String utilisateur
String nom du service
String nom de la méthode
... champ spécifique à la méthode

•  Nom d'utilisateur -  Il s'agit de l'identité d'autorisation que le client revendique.
•  Nom du service - Il s'agit de l'installation à laquelle le client demande l'accès.
•  Nom de la méthode - Il s'agit de la méthode d'authentification utilisée dans cette demande.

Le premier octet a la valeur décimale 50, qui est interprétée comme SSH-MSG USERAUTH_REQUEST. Un serveur peut accepter ou rejeter la demande d'authentification. En cas d'échec il nécessite une ou plusieurs authentifications supplémentaires.

L'échange de messages entre le client et le serveur implique les étapes suivantes :

1. Le client envoie un SSH_MSG_USERAUTH_REQUEST avec une méthode demandée nulle.
2. Le serveur vérifie si le nom d'utilisateur est valide. Sinon, le serveur renvoie SSH_MSG_USERAUTH_FAILURE avec la valeur de réussite partielle false. Si le nom d'utilisateur est valide, le serveur passe à l'étape 3.
3. Le serveur renvoie SSH_MSG_USERAUTH_FAILURE avec une liste d'une ou plusieurs méthodes d'authentification à utiliser.
4. Le client sélectionne l'une des méthodes d'authentification acceptables et envoie un SSH_MSG_USERAUTH_REQUEST avec ce nom de méthode et les champs spécifiques à la méthode requis. À ce stade, il peut y avoir une séquence d'échanges pour exécuter la méthode.
5. Si l'authentification réussit et que d'autres méthodes d'authentification sont requises, le serveur passe à l'étape 3, en utilisant une valeur de réussite partielle de true. Si l'authentification échoue, le serveur passe à l'étape 3, en utilisant une valeur de réussite partielle false.
6. Lorsque toutes les méthodes d'authentification requises réussissent, le serveur envoie un message SSH_MSG_USERAUTH_SUCCESS et le protocole d'authentification est terminé.

Le serveur peut nécessiter une ou plusieurs des méthodes d'authentification suivantes :

•  Clé publique : Cette méthode dépend de l'algorithme de clé publique sélectionné. Essentiellement, le client envoie un message au serveur qui contient la clé publique du client, avec le message signé par la clé privée du client. Lorsque le serveur reçoit ce message, il vérifie si la clé fournie est acceptable pour l'authentification et, si c'est le cas, il vérifie si la signature est correcte.
•  Mot de passe : le client envoie un message contenant un mot de passe en texte clair, qui est protégé par cryptage par le protocole de couche de transport.
•  Basé sur l'hôte : l'authentification est effectuée sur l'hôte du client plutôt que sur le client lui-même. Ainsi, un hôte prenant en charge plusieurs clients fournirait une authentification pour tous ses clients. Cette méthode fonctionne en demandant au client d'envoyer une signature créée avec la clé privée de l'hôte client. Ainsi, plutôt que de vérifier directement l'identité de l'utilisateur, le serveur SSH vérifie l'identité de l'hôte client, puis croit l'hôte lorsqu'il dit que l'utilisateur s'est déjà authentifié côté client.

Le protocole de connexion SSH fournit plusieurs connexions logiques sur une seule connexion SSG sous-jacente. Il s'exécute au-dessus du protocole de couche de transport SSH et du protocole d'authentification des utilisateurs et suppose qu'une connexion d'authentification sécurisée est utilisée. Cette connexion d'authentification sécurisée, appelée tunnel, est utilisée par le protocole de connexion pour multiplexer un certain nombre de canaux logiques.

Tous les types de communication utilisant SSH, comme une session de terminal, sont pris en charge à l'aide de canaux séparés. Chaque côté peut ouvrir un canal. Pour chaque canal, chaque côté associe un numéro de canal unique à une identité unique, qui n'a pas besoin d'être la même aux deux extrémités. Les canaux sont contrôlés en flux à l'aide d'un mécanisme de fenêtrage. Aucune donnée ne peut être envoyée à un canal jusqu'à ce qu'un message soit reçu pour indiquer que l'espace de fenêtre est disponible. La vie d'un canal passe par trois étapes : ouverture d'un canal, transfert de données et fermeture d'un canal.