Keychain/fr

Ce document décrit comment utiliser les clés partagées SSH avec le programme keychain. Il suppose que le lecteur a une connaissance de base de la cryptographie par clés publiques.

Le problème à résoudre
Ainsi vous disposez de cette merveilleuse machine Gentoo sur laquelle tourne, mais c'est un peu fatigant pour vous de continuer à taper tous ces mots de passe de connexion, n'est pas ? Ou peut-être avez vous un script ou une tâche de cron qui nécessite un moyen efficace d'utiliser une connexion ssh. Dans un cas comme dans l'autre, il y a une solution au problème, et elle commence avec l'authentification par clé publique.

=== Comment fonctionne l'authentification par clé publique ?

Supposons qu'un client veuille se connecter à sshd sur un serveur. Le client commence par générer une paire de clés et donne la clé publique au serveur. Par la suite, à chaque fois que le client essaye de se connecter, le serveur lui soumet un challenge qui est chiffré avec cette clé publique. Dans ce cas, seul le détenteur de la clé privée correspondante (le client) est capable de le déchiffrer, et vous l'aurez deviné, seul ce détenteur est à même de pouvoir donner la bonne réponse et réussir la connexion.

Générer une paire de clés
La première étape est de créer une paire de clés. Pour le faire, vous devez utiliser la commande   comme suit :

Contentez-vous d'accepter les valeurs par défaut, et assurer vous d'entrer une phrase de passe solide.

Vous devriez maintenant disposer d'une clé privée dans   et d'une clé publique dans. Vous êtes prêt à copier la clé publique sur l'hôte distant.

Préparation du serveur
Vous allez copier la clé sur le serveur qui exécute sshd. Vous allez aussi l'ajouter au fichier  qui appartient à l'utilisateur se connectant sur ce serveur. Voici un exemple sur la manière de le faire si vous avez déjà un accès ssh à ce serveur.

The output from that last line should show you the contents of the file. Make sure it looks correct.

Testing the setup
Theoretically, if all went well, and the ssh daemon on the server allows it, we should be able to get ssh access without a password on the server now. We will still need to decrypt the private key on the client with the passphrase we used before, but this should not be confused with the passphrase of the user account on the server.

Hopefully, it asked you for your passphrase for id_dsa, and you were able to gain ssh access as server_user on the server. If not, login as server_user, and verify the contents of to make sure each entry is on a single line. You might also want to check the sshd configuration to make sure that it prefers to use public key authorization when available.

At this point, you're probably thinking, "What's the point, I just replaced one password with another?!" Relax, the next section will show you exactly how we can use this to save your precious time.

Typical key management with ssh-agent
If you've been following along, you're probably thinking that it would be great if we could somehow decrypt our private key(s) once, and gain the ability to ssh freely, without any passwords. You are in luck, that is exactly what the program  is for.

The program  is usually started at the beginning of your X session, or from a shell startup script like. It works by creating a unix-socket, and registering the appropriate environment variables so that all subsequent applications can take advantage of it's services by connecting to that socket. Clearly, it only makes sense to start it in the parent process of your X session if you want to use the set of decrypted private keys in all subsequent X applications.

When you run ssh-agent, it should tell you the PID of the running ssh-agent, and also set a few environment variables, namely  and. It should also automatically add to it's collection and ask you for the corresponding passphrase. If you have other private keys you want to add to the running ssh-agent, you can use the  command as follows:

Now for the magic. Since you should now have your decrypted private key ready, you should be able to ssh into the server without entering any passwords.

It would be nice to know how to shut down ssh-agent in case you need to, right?

If you want even more convenience from ssh-agent, proceed to the next section on using keychain. Be sure to kill the running ssh-agent as in the example above if you decide to do so.

Squeezing the last drop of convenience out of ssh-agent
Keychain will allow you to reuse an ssh-agent between logins, and optionally prompt for passphrases each time the user logs in. Before we get ahead of ourselves though, let's emerge it first.

Assuming that was successful, we can now use keychain freely. Add the following to your to enable it:

Enabling keychain in .bash_profile

Let's test it. First make sure we killed the ssh-agent from the previous section, then start up a new shell, usually by just logging in, or spawning a new terminal. It should prompt you for the password for each key you specified on the command line. All shells opened after that point should reuse the ssh-agent, allowing you to make passwordless ssh connections over and over.

Using keychain with KDE
If you are a KDE user, instead of using, you can let KDE manage ssh-agent for you. In order to do so, you will have to edit, which is read during KDE's startup, and  , which is executed during KDE's shutdown. Here is how you could edit those files:

Editing /etc/kde/agent-startup.sh

Editing /etc/kde/shutdown/agent-shutdown.sh

Now, all you have to do is launch a term of your choice, like Konsole, and load the keys you would like to use. For example:

Your keys will be remembered until you end your KDE session or kill the ssh-agent manually.

Security considerations
Of course, the use of ssh-agent may add a bit of insecurity to your system. If another user were to use your shell while you were in the bathroom, he could login to all of your servers without passwords. As a result, it is a risk to the servers you are connecting to, and you should be sure to consult the local security policy. If you do use it, be sure to take the appropriate measures to ensure the security of your sessions.

Troubleshooting
Most of this should work pretty well, but if you encounter problems, you'll certainly want to know a few useful things.


 * If you are unable to connect without ssh-agent, consider using ssh with the arguments -vvv to find out what's happening. Sometimes the server is not configured to use public key authentication, sometimes it is configured to ask for local passwords anyway! If that is the case, you may want to also use the -o option with ssh, or change the server sshd_config.
 * If you are having problems with ssh-agent or keychain, it may be that you are not using a shell that understands the commands they use. Consult the man pages for ssh-agent and keychain for details on working with other shells.
 * You may also want to visit the keychain homepage for more usage tips.

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * Eric Brown
 * Marcelo Goes
 * nightmorph