Bien, commençons. L'ordre des opérations est relativement simple : générer une paire de clés, distribuer les clés publiques sur les serveurs sur lesquels nous allons nous connecter, puis configurer notre agent. Avant de commencer, assurons-nous que le serveur cible sache utiliser l'authentification par clé RSA.
$ grep RSA /etc/sshd_config RSAAuthentication yes |
Si la configuration dit « no », alors tout ça devient un sujet de conversation. Demandez à votre administrateur si vous en avez besoin.
Nous utilisons ssh-keygen pour générer la paire de clés. Une session classique reseemble à ça :
$ ssh-keygen Initializing random number generator... Generating p: ............................++ (distance 446) Generating q: ...............++ (distance 168) Computing the keys... Testing the keys... Key generation complete. Enter file in which to save the key (/home/jose/.ssh/identity): Enter passphrase: (not echoed) Enter the same passphrase again: (not echoed) Your identification has been saved in /home/jose/.ssh/identity. Your public key is: 1024 37 1381742407287909702550799142685822876412502877754788376289642432\ 595975854876231349873103003510711057121876416593846906376218762135709815\ 811196459231860453562718833268517306416528653414069780011020741244960739\ 348843757024741192066486942660583417436630931779421585690017354195391700\ 1003859838421924037121230161484169444067380979 jose@biocserver Your public key has been saved in /home/jose/.ssh/identity.pub |
Bien, nous avons maintenant les deux pièces manquantes, nos clés publique et privée. Il nous faut donc distribuer la clé publique. Franchement, c'est comme avec PGP, vous pouvez partager ceci avec n'importe qui, puis vous connecter sans incident. J'utiliserai scp pour la copier sur les autres machines :
$ scp .ssh/identity.pub jon2@li:~/.ssh/biocserver.pub jon2@li's password:(not echoed) identity.pub | 0 KB | 0.3 kB/s | ETA: 00:00:00 | 100% |
L'ayant copié là-bas, je vais maintenant me connecter sur la machine cible (dans notre cas la machine li du SCL) et l'ajouter à la liste des clés authorisées :
li$ cat biocserver.pub >> authorized_keys |
Ainsi, la machine li est prête à m'authentifier en utilisant ma clé privée RSA, clé générée ci-dessus. Retournons à ma machine cliente, et paramétrons ssh-agent. Tout d'abord, avant de lancer l'agent, regardons le contenu de quelques variables d'environnement de mon interpréteur de commandes :
$ env | grep -i SSH SSH_TTY=/dev/ttyp3 SSH_CLIENT=129.22.241.148 785 22 |
Lançons maintenant ssh-agent proprement. Il doit lancer un sous-interpréteur, donc nous devons lui préciser lequel pour qu'il puisse le paramétrer correctement :
$ ssh-agent /bin/bash |
Mon environnement est maintenant correctement paramétré :
$ env | grep -i SSH SSH_TTY=/dev/ttyp3 SSH_AGENT_PID=3012 SSH_AUTH_SOCK=/tmp/ssh-jose/ssh-3011-agent SSH_CLIENT=129.22.241.148 785 22 |
Les deux nouvelles variables SSH_AGENT_PID et SSH_AUTH_SOCK vont permettre à l'agent et aux applications connexes (le client ssh, le chargeur de cache de clés ssh-add, et autres du genre). Les sockets sont de simples fichiers dans le répertoire /tmp :
$ ls -l /tmp/ssh-jose/ total 0 srwx------ 1 jose users 0 Apr 24 13:36 ssh-3012-agent |
Maintenant que l'agent est paramétré correctement, chargez le cache avec votre clé privée. Souvenez-vous que l'agent communique avec le client pour lui fournir votre clé privée quand vous vous authentifiez. Le lancer sans arguments le fait charger le fichier de la clé par défaut :
$ ssh-add1 Need passphrase for /home/jose/.ssh/identity (jose@biocserver). Enter passphrase:(not echoed) Identity added: /home/jose/.ssh/identity (jose@biocserver) |
La phrase de passe que vous utilisez ici est faite pour s'assurer que « oui, c'est moi, j'ai le droit d'utiliser cette clé », et que c'est la même phrase de passe utilisée lorsque vous avez lancé ssh-keygen. Maintenant que la clé est chargée, regardons le contenu du cache, en utilisant l'option -l (pour liste) de ssh-add :
$ ssh-add -l 1024 37 1137558865696328451571189354697621649150131484876212929871995861\ 553162729709874182866289762398712097874714486515746971439573611270055860\ 187630540060660487199692328631713510202123260680797564262765311338987532\ 521475739334862853313810363888071565945239125248209981354764262500250893\ 7138181011315411800330612532401318392577 jose@biocserver |
Maintenant, quand vous utilisez ssh pour vous connecter à un autre serveur, la clé privée vous authentifiera grâce à ssh-agent !
$ ssh -l jon2 li Last login: Tue Apr 24 14:53:39 2001 from biocserver.bioc. You have mail. bash-2.03$ |
Notez que vous pouvez modifier cette façon de faire, pour y introduire de la flexibilité. Pour commencer, vous pouvez utiliser la sortie du programme ssh-agent (invoqué sans argument), pour modifier l'environnement de l'interpréteur de commandes courant et indiquer la socket de communication de l'agent :
$ eval `ssh-agent` Agent pid 19353; |
Vous pouvez maintenant ajouter des clés comme décrit ci-dessus, alors que vous n'avez pas démarré de sous-interpréteur, ayant simplement modifié l'interpréteur courant que vous utilisez. La commande eval et les apostrophes inverses sont nécessaires pour utiliser ce que l'agent fournit sur la sortie standard pour paramétrer votre environnement. Cela parce que les processus fils ne peuvent modifier les paramètres de l'interpréteur père.
Une seconde modification que vous pouvez appliquer est de démarrer votre bureau X, tel que Gnome ou KDE, en tant qu'argument à ssh-agent. Cela permettra à chaque client X démarré localement d'être capable de communiquer avec l'agent, permettant une plus grande facilité quand vous utilisez des émulateurs de terminaux pour vous connecter à d'autres serveurs.