SSH : les principes et l'authentification par cryptographie asymétrique

Générer une clé publique et une clé privée avec ssh-keygen.

13 avril 2011

Requis

Pour tester ces commandes il vous faut un accès sur un serveur SSH (Secure SHell) qui possède déjà une clé privée et une clé publique (normalement la génération des clés est automatique à l'installation du serveur dans /etc/ssh/ssh_host_rsa_key[.pub] ou /etc/ssh/ssh_host_dsa_key[.pub]).


Principes d'une connexion SSH



Bonjour

Il y a une phase de bonjour entre le client et le serveur durant laquelle ils apprennent à se connaître et échangent les algorithmes qu'ils connaissent pour négocier.

- Algorithme d'échange de clé. (par exemple diffie hellman)
- Algorithme de chiffrement symétrique pour la confidentialité.
- Algorithme de hachage pour l'intégrité.

Authentification du serveur

Le serveur envoie sa clé publique au client. Si ce n'est pas la première connexion, le client vérifie à l'aide de l'empreinte (fingerprint) que la clé est inchangée, sinon il vous demande si vous souhaitez la rajouter dans le fichier ~/.ssh/known_hosts. Pour être sûr d'ajouter une clé correcte et savoir que vous n'êtes pas victime d'un faux serveur, vous devez demander à l'administrateur sa fingerprint (par téléphone par exemple) et la comparer avec celle que vous recevez.

Une clé secrète générée aléatoirement et chiffrée avec la clé publique du serveur, est envoyée par le client. Seule la clé privée du serveur peut donc la déchiffrer. Cette clé est appelée clé de session et fait 256 bits.

Le serveur annonce au client qu'il a compris en chiffrant un message standard avec la clé secrète. Si le client, en utilisant la clé secrète, arrive à déchiffrer le message standard, il a la preuve qu'il communique avec la bonne personne.

Communication sécurisée

La clé secrète sert maintenant à la création d'un canal sécurisé dans lequel les messages sont transmis via la cryptographie symétrique (symetric cipher), celle-ci étant beaucoup moins lourde à gérer que la cryptographie asymétrique.

Notez que jusqu'à maintenant le client est identifié mais pas authentifié . En gros "je sais que c'est à toi que je parle, mais je ne sais pas qui tu es".

Authentification du client

C'est seulement après tout ça que le serveur demande à authentifier l'utilisateur. Pour ceci deux options : le mot de passe ou la cryptographie asymétrique. C'est ce dernier élément que nous allons étudier.

Les explications pour générer une paire de clés et se faire connaître du serveur vont suivre, pour l'heure continuons la théorie.

Le client envoie sa clé publique au serveur. Ce dernier vérifie que la clé est présente dans son fichier ~/.ssh/authorized_keys. Si c'est le cas il génère une clé aléatoire et la chiffre avec la clé publique du client (c'est le challenge). Si le client arrive à déchiffrer le challenge et à le renvoyer c'est qu'il possède la bonne clé privée, le serveur est donc sûr de son interlocuteur.


Générer des clés privées et publiques



Si vous avez tout suivi vous comprendrez qu'il nous faut :
- Une paire de clé.
- Que notre clé publique se trouve dans le fichier ~/.ssh/authorized_keys du serveur.
- Une passphrase qui chiffrera/déchiffrera notre clé privée. Cette étape n'est pas obligatoire, mais il est aberrant de ne pas la mettre en oeuvre. La meilleure des sécurités c'est d'avoir quelque chose que l'on connait (la passphrase) et quelque chose que l'on possède (la clé privée).

RSA (Rivest Shamir Adleman) et DSA (Digital Signature Algorithm) sont les deux principaux algorithmes de chiffrement asymétrique. Pour l'exemple j'utiliserai DSA qui est réputé plus sécurisé, plus rapide en signature, mais moins rapide dans les vérifications (chiffrement/déchiffrement) que RSA.

Génération d'une clé publique et d'une clé privée protégée par une passphrase

	# L'option f correspond au fichier de sortie (beaucoup de cas demandent à ce que le fichier se nomme id_dsa), C à un commentaire qui permet de distinguer des clés.
	# Il n'est pas sérieux d'ignorer la passphrase.
	# Par défaut la clé générée est de 1024 bits, ce qui est le minimum de nos jours.
	ssh-keygen -t dsa -C "Informatix" -f informatix
	

Nous voici donc avec nos deux clés : informatix est la clé privée et informatix.pub la clé publique. Si ce n'est pas fait automatiquement, placez ces clés dans le dossier ~/.ssh/ de votre poste.

Intégration de la clé publique dans le fichier ~/.ssh/authorized_keys du serveur

# Le port SSH par défaut est 22
ssh-copy-id -i ~/.ssh/informatix.pub "<utilisateur>@<hote> -p <port>"

# ou si ça ne fonctionne pas

cat ~/.ssh/informatix.pub | ssh <utilisateur>@<hote> 'cat >> ~/.ssh/authorized_keys'
	

Dans un prochain tutoriel, j'expliquerai comment donner nos clés privées à un agent SSH.

Une question de vocabulaire !



chiffrement : Transformation à l'aide d'une clé d'un message en clair (dit texte clair) en un message incompréhensible (dit texte chiffré) pour celui qui ne dispose pas de la clé de déchiffrement (en anglais encryption).

cryptogramme : message chiffré

décrypter : Retrouver le message clair correspondant à un message chiffré sans posséder la clé de déchiffrement. En anglais on casse la clé.

crypter : Avec les définitions du dessus on voit qu'il ne faut pas confondre décrypter et déchiffrer. Avec la définition de décrypter on se rend compte que crypter ne veut rien dire, le mot crypter n'existe pas dans la langue française.

Par
Créateur et administrateur.

Dans la même catégorie

SSH : Comment interdire l'authentification par mot de passe ?
Yes : la commande qui vous veut du mal
Fork bomb : la réplication infinie des processus au service du DoS

Commentaire(s)