Premiers pas dans l'authentification par l'agent

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$
Regarde, maman, sans la phrase de passe !

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.