Vous en avez peut-être marre de sans arrêt devoir taper un mot de passe pour vous connecter à vos serveurs en ssh. Pire, ça vous inquiète de devoir passer en clair un mot de passe dans un script qui a besoin d’une connexion ssh.

Mais saviez-vous les amis qu’il est tout à fait possible de se passer de ce mot de passe ? Il suffit pour cela de configurer une reconnaissance du client par clef ssh. C’est à dire que la machine à partir de laquelle vous vous connectez publie une clef (sa signature), laquelle sera enregistrée sur le serveur ssh.

Par la suite, le serveur ssh saura reconnaitre ce client. Ainsi, si la signature est identique, il ne demandera plus aucun mot de passe. Et tout ceci s’effectue en à peine quelques minutes !

Côté serveur, modification du sshd

La première chose à faire est d’aller effectuer une petite modification dans le fichier de configuration de ssh, le sshd_config. En effet, l’option de connexion sans mot de passe par clef est désactivée par défaut :

sudo nano /etc/ssh/sshd_config

# décommenter la ligne ci-dessous
AuthorizedKeysFile      %h/.ssh/authorized_keys

Une fois la ligne dé-commentée et le fichier enregistré, on redémarre le serveur ssh :

service ssh restart

Côté client, création et export des clefs ssh

Création de la clef

Là encore, l’opération est très simple et très rapide. On commence par créer une paire de clefs avec la commande ssh-keygen. On ne précisera pas de mot de passe pour protéger les clefs, cela nous permet de n’avoir rien à taper lorsque l’on doit se connecter à un serveur.

Nous laissons donc le mot de passe vide et je laisse également l’emplacement de sauvegarde des clefs par défaut – il suffit donc d’appuyer sur entrer.

Plusieurs algorithmes sont disponibles pour la création de clef ssh, le plus sécurisé étant le ed25519, c’est celui-ci que nous allons générer. Si cela vous intéresse vous pouvez lire un comparatif des différents algorithme sur le Stackexchange security. Quoi qu’il en soit, quelque soit l’algorithme utilisé, l’usage ne change ensuite absolument pas. L’avantage de ce dernier par rapport au RSA par exemple, est aussi d’avoir des clefs publiques plus courtes.

Prenez garde car les clefs DSA ne sont plus supportées à partir de OpenSSH 7.

ssh-keygen -t ed25519
Generating public/private rsa key pair.
Enter file in which to save the key (/home/buzut/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/buzut/.ssh/id_ed25519.
Your public key has been saved in /home/buzut/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:n2Blsvev8IXeCkPsAMEortJd/qm1BUEyMxsMbHgm5OA
The key's randomart image is:
+--[ED25519 256]--+
|...o.=B .        |
|.o+ * oX         |
| E.*  o o o      |
|  .   .. B       |
| o . o  S +      |
|o . . .. O o .   |
|.      ...O o .  |
|       .oo * +   |
|      ...   =oo  |
+----[SHA256]-----+

Si vous voulez générer une clef d’une longueur en particulier, vous pouvez utiliser l’option -b et lui passer la longueur de clef souhaitée en bits.

Export de la clef

Voici l’ultime et dernière étape avant de pouvoir se connecter sans entrer aucun mot de passe : exporter sur le serveur ssh, notre clef ssh nouvellement créée. Cette étape, triviale, s’effectue avec la commande ssh-copy-id user@serverAdress. Il va vous demander le mot de passe (pour la dernière fois). Une fois l’opération effectuée, testez : ssh user@serverAddress, hop vous devriez être connecté sans autre forme de procès, pratique !

Il peut arriver que la commande ssh-copy-id ne soit pas installée. Dans ce cas, on procède manuellement. Il faut copier la clef publique depuis le dossier de l’utilisateur qui l’a créé – donc ~/.ssh/id_rsa.pub – dans le authorized_keys du répertoire .ssh de l’utilisateur cible, sur le serveur auquel on veut se connecter (créez-le s’il n’existe pas déjà !).

Si cela vous semble un peu flou, pour le user root, il faudra coller la clef dans /root/.ssh/authorized_keys et pour la plupart des autres users, cela se passera dans /home/user/.ssh/authorized_keys.

Import de la clef

En parlant d’export, une même clef peut aisément être partagée entre différentes machines. Une machine de bureau et un portable par exemple. Lorsqu’on promène son .ssh d’une machine à l’autre, il faut bien veiller aux droits et au propriétaire des dossiers.

Sur Linux comme sur BSD (et donc Mac), chaque utilisateur dispose d’un dossier .ssh dans son dossier utilisateur. Il est possible d’avoir plusieurs clefs pour un même utilisateur. Vous pouvez par exemple importer sur votre Mac les clefs que vous venez de créer sur votre Linux.

Par prudence, on préférera les transférer sur une clef USB que de s’envoyer un mail ou de les faire passer par Dropbox…

Au niveau des permissions, comme c’est très souvent source d’erreur, le dossier ssh ainsi que les clefs doivent appartenir à l’utilisateur qui les utilisera :

chown -R your_user:your_user .ssh

Si vos utilisateurs n’ont pas le même nom sur les différentes machines, pensez-y ! En ce qui concerne les droits, 700 pour .ssh, 644 pour la clef publique et 600 pour la clef privée. Si vous avez également modifié le authorized_keys, c’est 600 également.

chmod 700 .ssh
chmod 644 id_ed25519.pub
chmod 600 .ssh/id_ed25519 .ssh/authorized_keys

Interdire la connexion par mot de passe

Maintenant que nous avons rendu notre système plus pratique, pourquoi ne pas aussi améliorer la sécurité en désactivant la connexion par mot de passe ? Ainsi, il vous sera impossible de vous connecter depuis tout ordinateur dont le certificat n’a pas été enregistré sur le serveur !

Pour ce faire, c’est très simple, décommenter et de mettre à no la directive suivante :

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no