Guide de Keychain pour Gentoo Linux

1.  Contexte

Le problème à résoudre

Peut-être disposez-vous d'un ensemble bien réjouissant d'ordinateurs qui utilisent tous Gentoo Linux. Si c'est le cas, vous exécutez probablement sshd sur ces ordinateurs, mais n'est-ce pas lassant de devoir toujours taper un mot de passe pour ouvrir une session à distance ? Peut-être avez-vous écrit un script ou une commande cron qui nécessiterait une connexion SSH qui puisse être établie sans taper de mot de passe. Il existe une solution à ces problèmes : utiliser l'authentification par clé publique.

Comment l'authentification par clé publique fonctionne-t-elle ?

Considérons le cas d'un client qui souhaite se connecter à un serveur sshd. Le client génère d'abord une paire de clés et donne la clé publique au serveur. Ensuite, à chaque fois que le client tente de se connecter, le serveur lui soumet un « défi » chiffré par le biais de la clé publique. Seul le détenteur de la clé privée correspondante (soit le client) est capable de le déchiffrer. Comme vous l'avez sans doute deviné, une réponse correcte au « défi » lancé par le serveur permet l'authentification.

2.  Comment utiliser l'authentification par clé publique ?

Générer votre paire de clés

La première étape est la création de votre paire de clés. Pour ce faire, utilisons la commande ssh-keygen comme suit :

$ ssh-keygen -t dsa
(Acceptez les valeurs proposées par défaut et assurez-vous d'utiliser une phrase de passe robuste.)

Vous devriez maintenant disposer d'une clé privée dans le fichier ~/.ssh/id_dsa et d'une clé publique dans ~/.ssh/id_dsa.pub. Nous somme prêts à copier la clé publique sur l'hôte distant.

Préparer le serveur

Nous allons copier le fichier ~/.ssh/id_dsa.pub sur le serveur qui exécute sshd. Nous allons aussi ajouter cette clé au fichier ~/.ssh/authorized_keys qui appartient à l'utilisateur dont on utilise le compte pour la connexion. Voici un exemple que vous pouvez utiliser si vous disposez déjà d'un accès SSH vers l'hôte distant.

$ scp ~/.ssh/id_dsa.pub nom_utilisateur@serveur:~/myhost.pub
$ ssh nom_utilisateur@serveur "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh nom_utilisateur@serveur "cat ~/.ssh/authorized_keys"

La sortie de la dernière commande liste le contenu du fichier ~/.ssh/authorized_keys. Assurez-vous qu'il contient les bonnes informations.

Tester la configuration

Si tout s'est bien passé et que le serveur distant le permet, vous devriez être capable de vous connecter par SSH au serveur sans fournir de mot de passe utilisateur. Vous devrez tout de même déchiffrer la clé privée située sur le client à l'aide de la phrase de passe définie plus tôt, mais ce n'est pas la même chose que de taper le mot de passe utilisateur.

$ ssh nom_utilisateur@serveur

Si tout va bien, vous aurez à taper votre phrase de passe pour id_dsa, puis vous obtiendrez l'accès par SSH au serveur. Si ce n'est pas le cas, connectez-vous à l'hôte distant (en utilisant le même compte utilisateur) et vérifiez le contenu du fichier ~/.ssh/authorized_keys ; assurez-vous que chaque entrée est sur une ligne séparée. Vous souhaiterez peut-être aussi vérifier la configuration de sshd pour vous assurer que ce dernier favorise l'authentification par clé publique dès que cela est possible.

À ce point, vous vous demandez peut-être : « À quoi cela rime-t-il ? Je n'ai qu'échangé un mot de passe pour un autre ! » La prochaine section répond à cette interrogation en vous montrant comment éviter la saisie d'un mot de passe et ainsi économiser un temps précieux.

3.  Rendre l'authentification par clé publique plus pratique

Gestion des clés avec ssh-agent

Si vous avez suivi les instructions qui précèdent, vous pensez sans doute qu'il serait bien pratique de ne déchiffrer notre clé privée qu'une seule fois, puis d'utiliser SSH librement sans avoir à taper de mot de passe. C'est exactement la fonction du programme ssh-agent.

ssh-agent est habituellement lancé au début de votre session X ou à partir d'un script shell tel que ~/.bash_profile. Il fonctionne en créant un socket UNIX et en paramétrant les variables d'environnement nécessaires pour que d'autres programmes puissent utiliser le service en se connectant au socket. Bien sûr, il est absolument nécessaire de lancer ce programme dans le processus parent de votre session X si vous souhaitez que vos applications X aient accès aux clés déchiffrées.

$ ssh-agent

Lorsque ssh-agent est exécuté, il devrait afficher le numéro d'identification de son processus (PID) et paramétrer quelques variables d'environnement, dont SSH_AUTH_SOCK et SSH_AGENT_PID. Il devrait aussi ajouter ~/.ssh/id_dsa à son ensemble de clés automatiquement, et vous demander la phrase de passe correspondante. Si vous souhaitez ajouter d'autres clés privées à ssh-agent, vous pouvez utiliser la commande ssh-add comme suit :

$ ssh-add fichier_contenant_une_clé

Voici le clou du spectacle. Puisque votre clé privée est maintenant déchiffrée, vous devriez pouvoir vous connecter au serveur par SSH sans avoir à entrer de mot de passe.

$ ssh serveur

Bien sûr, vous devriez aussi savoir comment arrêter ssh-agent si besoin est.

$ ssh-agent -k

Si vous souhaitez augmenter le niveau de confort fourni par ssh-agent, continuez votre lecture avec la section sur l'utilisation de keychain. Assurez-vous toutefois d'arrêter ssh-agent tel que décrit ci-dessus avant de poursuivre.

Profiter de toutes les possibilités de ssh-agent

Le programme keychain permet de réutiliser une instance de ssh-agent dans des sessions différentes et, si désiré, d'inviter l'utilisateur à entrer les phrases de passe à chaque ouverture de session. Avant d'aller plus loin, installons keychain.

# emerge keychain

Si cette commande s'exécute sans problème, vous pouvez alors utiliser keychain sans plus attendre. Ajoutez ce qui suit à votre ~/.bash_profile pour activer keychain :

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh
. ~/.keychain/$HOSTNAME-sh-gpg

Passons aux tests. D'abord, assurez-vous d'avoir arrêté ssh-agent tel que décrit à la section précédente, puis lancez un nouveau shell (par exemple en ouvrant une nouvelle session ou un nouveau terminal). Vous devriez être invité à entrer la phrase de passe correspondant à chacune des clés que vous avez spécifiées avec la commande présentée ci-haut. Tous les shells lancés après cela devraient réutiliser ssh-agent, ce qui vous permettra de vous connecter par SSH encore et encore sans jamais avoir à entrer un mot de passe.

Utilisation de keychain avec KDE

Si vous êtes utilisateur de KDE, au lieu d'utiliser ~/.bash_profile, vous pouvez laisser KDE gérer ssh-agent pour vous. Pour faire cela, vous devez editer /etc/kde/agent-startup.sh, qui est lu pendant le démarrage de KDE, et /etc/kde/shutdown/agent-shutdown.sh, qui est exécuté pendant son arrêt. Les modifications à apporter à ces deux fichiers sont :

if [ -x /usr/bin/ssh-agent ]; then
  eval "$(/usr/bin/ssh-agent -s)"
fi

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Maintenant, tout ce qu'il vous reste à faire est de lancer le terminal de votre choix, disons Konsole, et de charger les clés que vous souhaitez utiliser. Par exemple :

$ keychain ~/.ssh/id_dsa
(Entrez votre phrase de passe)

Vos clés seront mémorisées jusqu'à ce que vous terminiez votre session KDE ou fermiez ssh-agent manuellement.

4.  Conclusion

Sécurité

Bien sûr, l'utilisation de ssh-agent introduit un peu d'insécurité dans votre système. Si un collègue utilise votre shell pendant que vous êtes aux toilettes, il peut accéder à tous vos serveurs sans mot de passe. Cela accroît les risques pour ces serveurs ; vous devriez donc consulter la politique locale de sécurité. Si vous utilisez ssh-agent, prenez les mesures nécessaires pour assurer la sécurité de vos sessions.

Résolution des problèmes

Les procédures décrites dans ce document fonctionneront du premier coup pour la plupart des utilisateurs. Si ce n'est pas votre cas, les astuces suivantes vous aideront probablement à cerner le problème.

• Si vous ne pouvez vous connecter sans utiliser ssh-agent, exécutez ssh avec les options -vvv pour savoir ce qui se passe. Parfois, le serveur n'est pas paramétré pour utiliser l'authentification par clé publique. Dans certains cas, il est paramétré pour demander tout de même un mot de passe ! Si c'est le cas, vous pouvez utiliser l'option -o avec ssh, ou éditer le fichier sshd_config du serveur.
• Si vous avez des problèmes avec ssh-agent ou keychain, peut-être utilisez-vous un shell qui ne comprend pas les commandes utilisées par ces programmes. Consultez les pages man de ssh-agent et de keychain pour savoir comment adapter leur utilisation à d'autres shells.

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.