Authentification par clé publique avec SSH

20 août 2014

Objectif : créer un lien fort entre un client et un serveur SSH, de telle sorte que le client se connecte au serveur automatiquement sans demander de mot de passe.

Par défaut, seul le serveur est identifié par une clé publique, ce qui au passage permet d’initialiser le cryptage. La chose à retenir est que cette clé est en quelque sorte associée au nom du serveur dans une base client (~/.ssh/known_hosts), et si elle change le client est sensé avertir l’utilisateur que quelque chose ne va pas. Parfois c’est normal : le serveur a été réinstallé, la clé corrompue, etc les raisons ne manquent pas pour qu’une clé change… ça peut aussi être le fait d’une personne mal intentionnée, d’où l’avertissement. En tout état de cause, la personne qui s’occupe d’un serveur est sensée communiquer à ses clients si la clé change. Dans le doute, il vaut mieux ne pas se connecter à un serveur si une clé a changé et qu’on ne sait pas pourquoi.

Ici, on s’intéresse à créer une clé qui identifie le client auprès du serveur, il s’agit donc d’ajouter la clé dans une base serveur (~/.ssh/authorized_keys). Il est intéressant de noter que la clé est ajoutée dans le homedir d’un user bien spécifique : la connection automatique du client n’est donc possible que pour se connecter avec ce user. Il est ainsi possible d’utiliser cette même clé pour plusieurs users du serveur, voire sur plusieurs serveurs ! A vous de jouer finement avec ces possibilités.

Sur le client

Il faut déjà créer la clé, elle est personnelle au user et doit être bien protégée. En théorie, les systèmes mettent des droits appropriés pour ces fichiers (chmod 700), mais n’oubliez pas néanmoins que root peut tout voir, ou quelqu’un qui boot votre poste client avec un media de démarrage amovible (un linux live par exemple…)

Création de la clé :

> ssh-keygen -t rsa -b 2048
Enter file in which to save the key (/home/sioc/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/sioc/.ssh/id_rsa.
Your public key has been saved in /home/sioc/.ssh/id_rsa.pub.
The key fingerprint is:
27:15:22:dd:73:0b:d1:91:be:db:3c:09:75:81:9f:84 sioc@moustache
The key's randomart image is:
+--[ RSA 2048]----+
|      ....oo.oo  |
|       ...+.+E o |
|          .= .o o|
|         .  o .o.|
|        S .  o . |
|         o  o    |
|             = . |
|            . =  |
|               . |
+-----------------+

Quelques détails : l’emplacement par défaut est le bon, a priori pas besoin d’y toucher. Il est possible de sécuriser la clé avec un mot de passe, ce qui évite de se la faire voler, ou du moins limite les risques. On perd alors l’intérêt de la connexion automatique sans mot de passe, mais si on utilise la même clé sur plusieurs serveurs, le mot de passe demandé sera le même pour tous les serveurs, plutôt que le mot de passe de chaque serveur… à vous de voir : personnellement j’utilise des clés sans mot de passe associées à un unique poste client, en tout cas pour accéder à des serveurs pas trop critiques… Le fichier généré id_rsa est une combinaison de clés publiques/privées, ce fichier est critique et il doit être le plus protégé possible. Le fichier id_rsa.pub en revanche est la clé publique seule : c’est ce fichier qu’il faut diffuser sur le serveur. Les infos affichées à la fin sont le fingerprint et le randomart de votre clé : il s’agit d’une marque unique correspondant à la clé (un hash), qui sert à vérifier que votre clé n’a pas été corrompue (changée…). Le fingerprint est juste impossible à mémoriser, alors il parait que le randomart est sensé s’imprimer de manière visuelle dans la mémoire, spontanément et sans effort, de telle sorte que s’il change, on s’en rende compte naturellement…

Sur le serveur

Se connecter au serveur à l’ancienne, avec le mot de passe. Puis copier le contenu du fichier ~/.ssh/id_rsa.pub du client dans le fichier ~/.ssh/authorized_keys du serveur. Se déconnecter puis se reconnecter.

Si tout se passe bien la connexion devrait se faire sans mot de passe, félicitations !

Si ce n’est pas le cas, vérifier les droits sur les fichiers du serveur :

chmod 755 ~/.ssh
chmod 755 ~/.ssh/authorized_keys

Tagged with: security, ssh

Categorised as: Linux

Blogeek|Sioc