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
Having to type in login passwords on each and every system is inconvenient, especially if many systems are being managed. Some administrators might even have a need for a script or cron-job that needs a convenient way to use an ssh connection. Either way, there is a solution to this problem, and it begins with public key authentication.

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
The first step is to create a key pair. To do this, use the ssh-keygen command:

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

After the generation has ended a private key should be located at and a public key in. The public key is now ready to be copied to the remote host.

Préparation du serveur
The file needs to be copied over to the server running sshd. It has to be added to the file that belongs the connecting user on the remote server. After ssh access to the server has been granted by infrastructure personnel, the following steps can be used to setup automatic login using a public key on the remote server:

La sortie correspondant à la dernière ligne devrait vous montrer le contenu du fichier. Vérifiez bien qu'elle est correcte.

Tester la configuration
Theoretically, if all went well, and the sshd daemon on the server allows it (as this can be configured), ssh access without entering a password should now be possible on the server. The private key on the client will still need to be decrypted with the passphrase used previously, but this should not be confused with the password of the user account on the server.

It should have asked for a passphrase for, and then grant access via ssh as the user  on the server. If not, login as, and verify that the contents of  has each entry (which is a public key) on a single line. It is also a good idea to check the sshd configuration to make sure that it allows to use public key authorization when available.

À ce stade, vous pensez probablement, ''De qui se moque-t-on ? J'ai simplement échangé un mot de passe contre un autre !'' Détendez-vous, la section suivante va vous expliquer comment utiliser tout ça de manière à économiser votre précieux temps.

Gestion typique des clés avec un agent ssh
The next step is to decrypt the private key(s) once, and gain the ability to ssh freely, without any passwords. That is exactly what the program ssh-agent is for.

ssh-agent is usually started at the beginning of the 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 its services by connecting to that socket. Clearly, it only makes sense to start it in the parent process of an X session to use the set of decrypted private keys in all subsequent X applications.

When running ssh-agent</tt>, it should output 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 the user for the corresponding passphrase. If other private keys exist which need to be added to the running ssh-agent, use the ssh-add</tt> command:

Maintenant, la magie ! Comme vous devriez maintenant avoir vos clés privées déchiffrées et prêtes, vous devriez pouvoir vous connecter au serveur ssh sans entrer de mot de passe.

Il serait bon de savoir comment interrompre l'agent ssh au cas où vous en auriez besoin.

Si vous voulez encore plus de confort de l'agent ssh, lisez la section suivante sur l'utilisation de keychain. Assurez-vous de tuer l'agent ssh en fonctionnement, comme indiqué précédemment, si vous décidez de le faire.

Obtenir la dernière goutte de confort de ssh-agent
Keychain va vous permettre de réutiliser un agent ssh entre sessions et, en option, vous demander les phrases de passe à chaque entrée dans la session. Avant d'avancer néanmoins, commencez par l'installer.

En supposant que l'installation a réussi, vous pouvez utiliser keychain librement. Ajoutez ce qui suit à vote  pour l'activer.

Testez le maintenant. Tout d'abord, assurez-vous que l'agent ssh a été tué, puis démarrez un nouveau shell, ordinairement en vous connectant, ou en lançant un nouveau terminal. Il devrait vous inviter à entrer la phrase de passe pour chacune des clés que vous avez entrées sur la ligne de commande. Tous les shells ouverts après ce point devraient réutiliser l'agent ssh, vous autorisant ainsi à vous connecter indéfiniment en ssh sans saisir de mot de passe.

Utiliser keychain avec KDE
KDE users, instead of using, can let KDE manage ssh-agent for them. In order to do so, edit, which is read during KDE's startup, and , which is executed during KDE's shutdown. Here is how one could edit those files:

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

Vos clés seront mémorisées jusqu'à ce que vous mettiez fin à votre session KDE ou que vous tuiez l'agent ssh à la main.

Considération sur la sécurité
Bien-sûr, l'utilisation de ssh-agent peut ajouter une dose d'insécurité à votre système. Si un autre utilisateur était à même d'utiliser votre shell alors que vous êtes à la machine à café, il pourrait se connecter à tous vos serveurs sans mot de passe. En conséquence, c'est un risque pour les serveurs auxquels vous vous connectez, et vous devriez consulter la politique locale de sécurité. Si vous l'utilisez, prenez les mesures appropriées pour garantir la sécurité de vos sessions.

Dépannage
La majeure partie de tout ceci devrait fonctionner sans problème, mais si vous rencontrez une difficulté, vous devriez certainement connaître quelques points utiles.


 * If connecting without ssh-agent</tt> does not seem to work, consider using ssh with the arguments  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, try using the   option with ssh</tt>, or change the server's.
 * If connecting with ssh-agent</tt> or keychain</tt> does not seem to work, then it may be that the current shell does not understand the commands used.. Consult the man pages for ssh-agent and keychain for details on working with other shells.

External resources

 * Official project page
 * IBM developerWorks article series introducing the concepts behind Keychain