Keychain
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.
Keychain is a frontend to ssh-agent and ssh-add, allowing long running sessions and letting the user enter passphases just once. It can also be used to allow scripts access to SSH connections.
Fondamentaux
Le problème à résoudre
Avoir à entrer un mot de passe de connexion sur chaque système est peu pratique, surtout 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-keygenAccepter les valeurs par défaut, et s'assurer d'entrer une mot de passe fort.
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.
Adding or changing a passphrase for the private key can be done as follows:
user $ssh-keygen -p -f ~/.ssh/id_rsaPré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 serveur_utilisateur@serveur -i ~/.ssh/id_rsa.pubssh-copy-id est un script permettant d'automatiser ces étapes. S'il n'est pas disponible, les commandes suivantes peuvent être utilisées :
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`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 somekeyfileMaintenant, 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 serverPour interrompre l'agent ssh (et du coup demander d'entrer un mot de passe de nouveau) :
user $ssh-agent -kIl 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/keychainEn supposant que l'installation ait réussie, keychain peut maintenant être utilisé librement. Ajouter ce qui suit au fichier ~/.bash_profile pour l'activer :
Add the following to the shell initialization file (~/.bash_profile, ~/.zshrc, or similar) to enable it:
'"`UNIQ--pre-00000001-QINU`"'
~/.zshrcEnabling Keychain in zshkeychain ~/.ssh/id_rsa
. ~/.keychain/${HOST}-sh
. ~/.keychain/${HOST}-sh-gpg
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.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.
All shells opened after that point should reuse the ssh-agent, allowing to use passwordless SSH connections over and over.
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 :
Here is how one could edit those files:
SSH_AGENT=true
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_rsaLes clés seront mémorisées jusqu'à la fin à la session de Plasma (ou jusqu'à ce que l'agent ssh soit tué manuellement).
Alternatively use KWallet with kde-plasma/ksshaskpass under Plasma 5
You can also have Plasma automatically ask you for your passphrase upon desktop login. Emerge kde-plasma/ksshaskpass, which will set up an environment variable to use the ksshaskpass application whenever ssh-add is run outside of a terminal. Then create a script as follows, and install it via the Plasma -> System Settings -> Startup and Shutdown -> Autostart.
~/ssh.shCreate ssh.sh script#!/bin/sh
ssh-add < /dev/null
Recent versions of plasma seem to require autostart scripts to have user-only permissions. You may need to
chmod 700 ssh.sh before adding the script via the Autostart GUIConclusion
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
-vvvpour 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-oavec 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.
Voir aussi
- SSH — the ubiquitous tool for logging into and working on remote machines securely.
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.
This page 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,
They are listed here because 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 each article's associated history page.