Carte d’identité de SSH

Qu’est-ce-que SSH ?

SSH pour Secure SHell est avant tout un protocole qui permet d’établir une session de communication sécurisée entre 2 terminaux/machines. La machine qui initie la communication est le client; le serveur étant l’hôte auquel le client souhaite se connecter. 

Basé sur le modèle client-serveur, SSH est donc un protocole de la couche 7 (application) du modèle OSI. Il est défini au travers de la RFC 4251. SSH est actuellement dans sa version 2 (SecSh v2, SSH2).

Par défaut, le serveur écoute sur le port TCP 22. 

SSH a été élaboré notament pour palier les lacunes des protocoles en texte clair comme Telnet, FTP (remplacé par SCP et SFTP…).

Pour parvenir à sécuriser la communication SSH a recours à différents mécanismes cryptographiques. Ces mécanismes sont au nombre de 3:

• le chiffrement symétrique (*)
• le chiffrement asymétrique
• le hashage

(*) Contrairement à ce que pourrait laisser croire l’usage de paire de clés, le protocole SSH a principalement recours au chiffrement symétrique y compris lors de communications ayant recours à l’authentification par clés. Le chiffrement asymétrique est uniquement utilisé lors de l’authentification des 2 parties (clé serveur et le cas échéant clé client). Le reste de la communication s’opère dans le cadre d’un chiffrement symétrique. Le chiffrement symétrique permet notamment d’implémenter la confidentialité avant l’authentification du client (par mot de passe ou par clés).

Comment fonctionne SSH plus en détail ? 

Un peu plus en détail, voici ce qu’il se passe suite à l’initiation d’une connection SSH:

• Les 2 parties entament la négociation des formats et des algorithmes de chiffrement, de hachage, d’échange de clés (key exchange – kex) et des clés publiques (entre autres) avec l’envoi du message SSH_MSG_KEXINIT.
• Lorsque le client et le serveur supportent au moins un algorithme et format en commun  pour chacune des catégories, les 2 parties déduisent selon la même logique les formats et algorithmes à utiliser. Le client et le serveur passent à l’étape suivante.
• Ainsi démarre la phase d’échange de clés durant laquelle l’identité du serveur (host key) est vérifiée par le client. Cette étape s’appuie sur la méthode Diffie-Hellman qui consiste pour chacune des 2 parties à générer un secret partagé (shared secret) commun ne pouvant être déterminé par une seule des parties.
• Pour ce faire, le client applique une formule à un nombre choisi aléatoirement (x) dans une plage finie (1 < x < q) puis envoie le résultat (e) au serveur. Ce dernier renvoie au client 3 informations: une signature (s), sa clé publique (host key) et le résultat (f) de la même formule appliquée à un nombre aléatoire (y) extrait depuis une plage finie quasi identique à celle utilisée par le client (0 < y < q). La signature « s » est obtenue en combinant sa clé privée à un hash (H) incluant le résultat « e » et la clé secrète (K) elle-même obtenue à partir d’une formule impliquant « e » et « y ». 
• Le client s’assure que la clé publique est bien celle du serveur par le biais soit de certificats (PKI), soit d’une base de données locale (fichier know_hosts). Bien que recommandée pour se prémunir contre des attaques, cette vérification peut toutefois être supprimée pour des raisons pratiques.
• Le client détermine à son tour la valeur de « H » et la clé secrète « K ». Pour deviner la clé « K », le client a recours à une formule  impliquant « f » et « x ». La clé publique du serveur quant à elle permet au client de valider que la signature correspond bien à la clé privée.
• Le client vérifie ensuite la signature « s » sur « H ». Si le test est concluant alors le client et le serveur connaissent forcément les valeurs de « K » et de « H » sans jamais les avoir échangées (en texte clair).
• Puis chacune des parties génère par dérivation les clés de chiffrement et d’authentification à partir de « H » et de la clé secrète « K » en appliquant le même algorithme de hachage que celui utilisé précédemment pour obtenir « H ».
• L’échange de clés s’achève avec le message SSH_MSG_NEWKEYS. A partir de cet instant, tous les messages échangés sont chiffrés à l’aide des algorithmes négociés ainsi que des nouvelles clés.
• A son tour, le client s’authentifie auprès du serveur à l’aide soit d’un mot de passe, soit d’une paire de clés.
• Si l’authentification est réussie alors le serveur attribue au client une session de shell interactif ou de transfert de fichier.

Ci-dessous le workflow d’une session SSH jusqu’à l’envoi du premier paquet chiffré:

Les algorithmes de chiffrement et les longueurs de clés supportés

Pourquoi utiliser SSH ?

• Un serveur distant s’exécutant sur une plate-forme cloud comme AWS EC2
• Un équipement réseau (routeur, switch…)
• Un serveur de fichiers sécurisé

Comment utiliser SSH ?

• Le client SSH initie la connexion à un serveur SSH s’éxécutant sur une machine distante
• Le client s’authentifie avec une clé secrete ou avec un mot de passe
• Si l’authentification est réussie,  le client accède à une session sur la machine distante.

La pratique

L’authentification par clés (recommandée)

L’ensemble des commandes ci-dessous requiert le package openssh-client. OpenSSH (client et serveur) est également disponible sous Windows sans passer par Cygwin ni autre logiciel tiers (voir ici).

Générer une paire de clés

# Par défault la clé générée aura une longueur de 3072 bits 
# et utilisera l'algorithme de chiffrement RSA 
ssh-keygen -f $SSH_KEY_FILE

 Pour définir la longueur ainsi que l’algorithme de la clé, on peut spécifier des arguments à l’aide des switches -t et -b comme suit:

ssh-keygen -t dsa         # A éviter
ssh-keygen -t rsa -b 4096
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Copier la clé publique sur le serveur

Afin de copier une clé publique sur un serveur SSH (fichier authorized_keys), utilisez la commande:

ssh-copy-id $USER@$SSH_SERVER -i $IDENTITY_FILE

Le switch -i permet – dans le cas où plusieurs fichiers de clé publique sont présents – de spécifier le fichier à utiliser.

Se connecter au serveur

Pour se connecter au serveur rien de plus simple :

ssh $USER@$SSH_SERVER -i $IDENTITY_FILE

Conclusion

SSH est aujourd’hui un protocole largement utilisé. Il a depuis sa création en 1995 et suite à ses améliorations successives fait ses preuves en matière de sécurité.

Il est recommandé d’employer pour le client l’authentification par clés – moins vulnérable aux attaques « brut force » et par dictionnaire que l’authentification par mot de passe.

Pour toutes ces raisons, il est évident que SSH a encore quelques années devant lui.