Keychain/fr

Ce document explique comment utiliser les clés SSH partagées avec le programme keychain. Il suppose une connaissance des fondamentaux de la cryptographie à clé publique.

Le problème à résoudre
Avoir à entrer un mot de passe de connexion sur chaque système est inconvénient, spécialement si beaucoup de systèmes sont gérés. Certains administrateurs peuvent même avoir besoin d'un script ou d'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 ?
Supposer qu'un client veuille se connecter au démon ssh 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 la bonne réponse permet de 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 ce faire, utiliser la commande  :

Accepter les valeurs par défaut, et s'assurer d'entrer une mot de passe fort.

Après la génération terminée, une clé privée doit se trouver dans  et une clé publique dans. La clé publique est maintenant prête à être copiée sur l'hôte distant.

Préparer le serveur
La clé doit être copiée sur le serveur qui exécute. Elle doit être ajoutée au fichier qui appartient à l'utilisateur se connectant sur le serveur. Après que l'accès ait été autorisé, les étapes suivants peuvent être utilisées pour configurer la connexion automatique au serveur en utilisant une clé publique.

La sortie correspondant à la dernière ligne devrait montrer le contenu du fichier. Bien vérifier que la sortie est correcte.

Tester la configuration
En théorie, si tout c'est bien passé, et si le démon sur le serveur le permet (cela peut être configuré), il devrait être possible d'avoir un accès  sur le serveur sans donner de mot de passe. La clé privée aura toujours besoin d'être décryptée sur le client avec le mot de passe défini précédemment, mais il ne faut pas confondre cela avec le mot de passe du compte utilisateur sur le serveur.

Un mot de passe a dû être demandé pour, et l'accès a dû être attribué vi à l'utilisateur   sur le serveur. Si ce n'est pas le cas, se connecter en tant que, et vérifier que le contenu de  comporte chaque clé publique sur une seul ligne. C'est aussi une bonne idée de vérifier la configuration de sshd pour être sûr qu'il autorise l'utilisation de clés publiques quand disponibles.

À ce stade, les lecteurs se demandent 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 expliquer comment utiliser tout ça de manière à n'entrer le mot de passe qu'une fois et réutiliser la clé (déchiffrée) pour de multiples connexions.

Gestion typique des clés avec un agent ssh
La prochaine étape est de ne déchiffrer la clé privé qu'une seule fois, et d'obtenir la possibilité de se connecter en ssh librement, sans avoir à taper aucun mot de passe. C'est exactement ce que le programme permet.

est en général lancé au démarrage de la session X, ou depuis un script de démarrage tel que. Il fonctionne en créant un socket Unix, et en enregistrant les variables d'environnement appropriées de telle manière que les applications suivantes puissent utiliser ces services en se connectant au socket. Clairement, cela n'a de sens que si le programme est démarré dans le processus parent de la session X si un le de clés privées déchiffrées est utilisé dans toutes les applications X ultérieures.

Quand est lancé, il devrait indiquer le  PID (identifiant du processus) du programme ssh-agent en exécution, et aussi définir quelques variables d'environnement, nommément, SSH_AUTH_SOCK et SSH_AGENT_PID. Il devrait aussi ajouter à sa collection et demander l'utilisateur le mot de passe correspondant. Si d'autres clés privées existantes doivent être ajoutées à l'agent en exécution, utiliser la commande :

Maintenant, la magie ! Avec les clés privées déchiffrées et prêtes, se connecter au serveur ssh (configuré pour utiliser les clés publiques) sans entrer de mot de passe :

Pour interrompre l'agent ssh (et du coup demander d'entrer un mot de passe de nouveau) :

Pour encore plus de confort d'utilisation avec ssh-agent, lire la section suivante sur l'utilisation de keychain. S'assurer de tuer le processus ssh-agent en fonctionnement vu que keychain se chargera de gérer les sessions de lui-même.

Obtenir le meilleur de ssh-agent
Keychain permettra de réutiliser un agent ssh entre sessions et, en option, de demander les mots de passe à chaque fois que les utilisateurs se connectent. Commencer par l'installer :

En supposant que l'installation ait réussie, peut maintenant être utilisé librement. Ajouter ce qui suit au fichier  pour l'activer :

Maintenant, tester. Tout d'abord, s'assurer que le processus ssh-agent de la section précédente a bien été tué, puis démarrer un nouveau shell, normalement en se connectant, ou en lançant un nouveau terminal. Il devrait inviter à entrer le mot de passe pour chacune des clés spécifiées sur la ligne de commande. Tous les shells ouverts après ce point devraient réutiliser l'agent ssh, autorisant ainsi à se connecter indéfiniment en ssh sans saisir de mot de passe.

Utiliser keychain avec Plasma 5
Les utilisateurs de Plasma 5, au lieu d'utiliser, peuvent confier à Plasma le soin de gérer l'agent ssh pour eux. Pour cela, modifier, qui est lu au démarrage de Plasma, et , qui est exécuté à l'arrêt de Plasma. Voici comment l'un pourrait s'y prendre :

Now, all that has to be done is launch a terminal of choice, like, and load the right set of keys to use. For example:

Les clés seront mémorisées jusqu'à la fin à la session de Plasma (ou jusqu'à ce que l'agent ssh soit tué manuellement).

Utiliser keychain avec Plasma 4
Comme précédemment pour Plasma 5 sauf qu'il faut remplacer avec.

Considérations sur la sécurité
Bien-sûr, l'utilisation de ssh-agent peut ajouter une dose d'insécurité au système. Si un autre utilisateur était en mesure d'accéder à un shell, il pourrait se connecter à tous les serveurs sans mot de passe. En conséquence, c'est un risque pour les serveurs, et les utilisateurs devraient consulter la politique locale de sécurité (s'il y en a une). S'assurer de prendre les mesures appropriées pour garantir la sécurité de toutes les sessions.

Dépannage
La majeure partie de tout ceci devrait fonctionner sans problèmes, mais si des problèmes surgissent, les points suivants peuvent s'avérer utiles.


 * If connecting without does not seem to work, consider using ssh with the   options 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, or change the server's.
 * If connecting with or  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.

Ressources externes

 * The official Keychain project page sur Funtoo.org (en anglais).
 * La suite d'article IBM developerWorks (en anglais) introduit les concepts derrière Keychain.