Différences

Ci-dessous, les différences entre deux révisions de la page.

--- keychain [2013/10/15 11:00] – luc
+++ keychain [2018/10/13 20:32] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 1: / Ligne 1: @@
+=====Keychain, un gestionnaire de clé=====
+====C'est quoi ?====
+===Situation initiale===
+Vous avez votre [[ssh|connection distante (ssh)]] configurée, vous avez mis en place un [[pubkey|système d'identification par clé (pubkey)]] pour ne pas avoir à taper votre mot de passe à chaque connexion, clé publique protégée par une //passphrase//. \\
+C'est bien, bravo.\\
+Mais quel est l'intérêt de taper à chaque fois une //passphrase// plutôt qu'un mot de passe ? ceci a déjà été détaillé ailleurs, mais revenons un peu dessus : il existe des outils qui vous demande votre //passphrase// lors de votre connexion et qui s'en souvienne pendant toute la durée de votre connexion, et parfois même après votre déconnexion, et tant que l'ordinateur ne redémarre pas, ils "tapent" vos passphrases à votre place. ''Keychain'' sert à ça.\\
+Vous allez me dire que des outils inclus dans le paquet openssh existent déjà, comme ''ssh-agent'' et qu'ils font très bien leur travail, alors pourquoi un autre outil ? Et moi je vous répondrais "Oui, mais .."
+===Oui, mais...===
+Si vous souhaitez utiliser une connexion distante dans un script, par exemple une sauvegarde à base de [[rsync]], [[sftp]] ou autre... lancée par cron, bah voilà, votre bel outil ''ssh-agent'' ne marche plus. Pourquoi le monde est-il si injuste ?\\
+Il semblerait que ce soit des histoires d'environnement, mais je vous avoue que je ne connais pas tous les détails. \\
+Il nous faut donc trouver une solution qui permette à nos scripts lancés par cron d'avoir accès à cette connexion par clé publique déjà déverrouillée par ''ssh-agent'' ou autre. ''Keychain'' sert à ça. (Vous voyez, on finit par y arriver :p )
+====Principe de fonctionnement====
+Vous lancez ''keychain'' une 1ère fois, il lance ''ssh-agent'' et vous demande vos //passphrases//, il enregistre "l'environnement" (pid ?) de ''ssh-agent'' dans un dossier à lui ''~/.keychain/'', et dans vos scripts vous appelez ''keychain'' qui fait le lien avec ''ssh-agent'' et vos clé sont utilisables.
+====Installation====
+===Paquet===
+Sous Debian, keychain est un paquet que l'on peut facilement installer via aptitude. \\
+Sous CentOS, je ne l'ai pas encore installé, mais il semblerait qu'il ne soit pas présent dans les dépots de base, ni ceux d'EPEL, ni ceux  de remi...
+===Configuration===
+J'ai trouvé quelque part une recommandation de lancer ''keychain'' systématiquement lorsqu'on se connecte en console. C'est pratique et ça ne coûte pas grand chose. Alors zou, c'est parti :\\
+dans votre fichier ''~/.bashrc'', on rajoute les lignes suivantes :
+<code bash>/usr/bin/keychain $HOME/.ssh/votre_super_cle_privée
+source $HOME/.keychain/$HOSTNAME-sh</code>
+Comme vous avez pu le remarquer, il convient d'avoir un dossier ''~/.keychain'', alors créons le et protégons le
+<code bash>mkdir ~/.keychain
+chmod 700 ~./keychain</code>
+====Utilisation====
+Dans vos scripts, il suffit de rajouter les lignes suivantes :
+<code bash>/usr/bin/keychain
+source $HOME/.keychain/votre_hostname-sh</code>
+Et pouf, ça fait des chocapic ! ou presque...
+====Optimisation====
+Certains vous dirait qu'on peut récupérer le HOSTNAME avec une commande, le stocker dans une variable, et le réutiliser... Ok pourquoi pas. L'avantage ? vous n'avez qu'à copier les lignes suivantes et les mettre dans votre script, y'a plus besoin de modifier quoi que ce soit (enfin, j'espère ;-) )
+<code bash>/usr/bin/keychain
+hostname=`uname -n`
+source $HOME/.keychain/$hostname-sh</code>