Keychain

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Keychain and the translation is 97% complete.

Other languages:
English • ‎español • ‎français • ‎日本語 • ‎한국어 • ‎polski • ‎русский • ‎中文(中国大陆)‎

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.

Fondamentaux

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.

Comment utiliser l'authentification par clé publique ?

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 ssh-keygen :

user $ssh-keygen

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

Attention !
S'assurer bien de choisir un mot de passe fort, en particulier si cette clé va être utilisée pour des connexions en tant qu'utilisateur root !

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

Préparer le serveur

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

user $ssh-copy-id server_user@server -i ~/.ssh/id_rsa.pub

ssh-copy-id is a wrapper script for these steps. If this wrapper script is unavailable, then the following steps can be used:

user $scp ~/.ssh/id_rsa.pub server_user@server:~/myhost.pub
user $ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
user $ssh server_user@server "cat ~/.ssh/authorized_keys"

La sortie correspondant à la dernière ligne devrait montrer le contenu du fichier ~/.ssh/authorized_keys. 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 sshd sur le serveur le permet (cela peut être configuré), il devrait être possible d'avoir un accès ssh 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.

user $ssh <server_user>@<server>

Un mot de passe a dû être demandé pour id_rsa, et l'accès a dû être attribué vi ssh à l'utilisateur <server_user> sur le serveur. Si ce n'est pas le cas, se connecter en tant que <server_user>, et vérifier que le contenu de ~/.ssh/authorized_keys 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.

Rendre commode l'authentification par clé publique

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 ssh-agent permet.

ssh-agent est en général lancé au démarrage de la session X, ou depuis un script de démarrage tel que ~/.bash_profile. 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.

user $eval `ssh-agent`
Note
Le programme ssh-agent conserve les clés déchiffrées jusqu'à ce qu-il soit tué. Pour définir une durée de vie pour les clés, utiliser l'argument -t comme expliqué dans la page de manuel man ssh-agent.

Quand ssh-agent 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 ~/.ssh/id_dsa à 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 ssh-add :

user $ssh-add somekeyfile

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 :

user $ssh server

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

user $ssh-agent -k
Note
Il est possible d'avoir plusieurs processus de ssh-agent fonctionnant en même temps, surtout quand la configuration a nécessité beaucoup de tentatives de d'effort. Ces processus peuvent être tués comme n'importe quel autre processus en exécutant killall ssh-agent.

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 ssh-agent 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 :

root #emerge --ask net-misc/keychain

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

CODE Activer keychain dans .bash_profile
keychain ~/.ssh/id_rsa
. ~/.keychain/$HOSTNAME-sh
. ~/.keychain/$HOSTNAME-sh-gpg
Note
Plus de clés privées peuvent être ajoutées à la ligne de commande si désiré. De plus, pour que le mot de passe soit demandé à chaque fois qu'un shell est créé, ajouter l'option --clear.
Note
Si bash n'est pas utilisé, lire la section EXAMPLES de la page man keychain pour des exemples d'utilisation avec d'autres shell. L'idée est de lancer ces commandes à chaque fois qu'un shell est utilisé.

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 ~/.bash_profile, peuvent confier à Plasma le soin de gérer l'agent ssh pour eux. Pour cela, modifier /etc/kde/startup/agent-startup.sh, qui est lu au démarrage de Plasma, et /etc/kde/shutdown/agent-shutdown.sh, qui est exécuté à l'arrêt de Plasma. Voici comment l'un pourrait s'y prendre :

CODE Modifier /etc/plasma/startup/10-agent-startup.sh
SSH_AGENT=true
CODE Modifier /etc/plasma/shutdown/10-agent-shutdown.sh
if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Maintenant, tout ce qu'il reste à faire, c'est de lancer un terminal, comme kde-apps/konsole, et de charger les bonnes clés à utiliser. Par exemple :

user $keychain ~/.ssh/id_rsa

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 /etc/plasma avec /etc/kde.

Conclusion

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.

  • Si se connecter sans ssh-agent semble ne pas fonctionner, considérer l'idée de se connecter en ssh avec l'argument -vvv pour identifier ce qui ne va pas. Parfois le serveur n'est pas configuré pour utiliser l'authentification par clé publique, parfois il est configuré pour demander un mot de passe quoi qu'il arrive ! Si c'est le cas, tenter d'utiliser l'option -o avec ssh, ou changer la configuration du serveur dans sshd_config.
  • Si se connecter avec ssh-agent ou keychain semble ne pas fonctionner, cela peut venir du fait que le shell utilisé ne comprend pas les commandes utilisées. Consultez les pages de man pour ssh-agent et keychain pour obtenir des informations sur comment les utiliser avec d'autres shells.

Ressources externes



This article is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Marcelo Goes, nightmorph
They are listed here as the Wiki history does not allow for any external attribution. If you edit the Wiki article, please do not add yourself here; your contributions are recorded on the history page.