SSH est le protocole le plus utilisé pour administrer des serveurs Unix à distance.
Il y a plusieurs façons de s’authentifier avec SSH, la plus courante étant l’utilisation d’un mot de passe associé à un compte UNIX sur le serveur distant.
Cependant, comme nous l’avons vu dans l’article Mettre en place une authentification par clé SSH, on peut s’authentifier via l’utilisation d’un fichier spécial appelé Clé Privée, tant que le serveur l’autorise grâce à sa jumelle, la Clé Publique.
Il est possible de charger une clé privée dans un agent qui la gardera disponible, même si celle-ci est protégée par un mot de passe. L’agent gardera la clé en mémoire, déverouillée, rendant son utilisation quotidienne plus aisée.
Mise en place de l’agent SSH
L’agent OpenSSH est un processus qui tourne en arrière plan. Les outils de la suite OpenSSH (ssh, scp, etc.) se connecte à l’agent à travers une socket UNIX spécifiée dans la variable d’environnement SSH_AUTH_SOCK.
La plupart des systèmes d’exploitation modernes démarrent un agent SSH lors de la connexion graphique d’un utilisateur (Mac OS X, Linux, etc.). Si ce n’est pas le cas, vous pouvez lancer un agent manuellement en utilisant la commande ssh-agent. L’agent écrira des commandes sur sa sortie standard qu’il faudra taper dans votre shell pour activer l’accès à l’agent. Le plus simple est d’utiliser la commande eval :
shell$ eval $(ssh-agent) Agent pid 91045
L’agent est maintenant fonctionnel, mais il ne possède pas encore de clé.
Gestion des clés dans l’agent
Vos clés SSH sont habituellement stockées dans ~/.ssh, bien qu’elles pourraient être stockées n’importe où. Elles pourraient même se situer sur des médias amovibles, comme par exemple sur une clé USB.
shell$ ssh-add -l The agent has no identities.
Dans cet exemple, nous avons deux paires de clé SSH dans ~/.ssh :
shell$ ls -l ~/.ssh/id_rsa* -rw------- 1 john.doe ucb 3326 Apr 4 2018 /Users/john.doe/.ssh/id_rsa -rw-r--r-- 1 john.doe ucb 3311 Apr 4 2018 /Users/john.doe/.ssh/id_rsa.pub -rw------- 1 john.doe ucb 3243 Apr 5 2018 /Users/john.doe/.ssh/id_rsa.prod -rw-r--r-- 1 john.doe ucb 753 Apr 5 2018 /Users/john.doe/.ssh/id_rsa.prod.pub
Nous allons maintenant charger ces deux clés privées dans l’agent en utilisant la commande ssh-add.
shell$ ssh-add .ssh/id_rsa Identity added: .ssh/id_rsa (.ssh/id_rsa) shell$ ssh-add .ssh/id_rsa.prod Enter passphrase for .ssh/id_rsa.prod: ************ Identity added: .ssh/id_rsa.prod (.ssh/id_rsa.prod)
Dans notre cas, la première clé n’est pas protégée par un mot de passe, elle est donc directement ajoutée à l’agent. La seconde clé, quant à elle, est protégée et doit être déverouillée avant d’être ajoutée. La commande ssh-add demande le mot de passe, puis charge la clé en mémoire. La clé pourra désormais être utilisée sans avoir à la déverouiller à chaque utilisation.
shell$ ssh-add -l 4096 SHA256:ZThQ6vRvCJDifvw0pzQSljane5AZBQqdAOOkNjd/HGc .ssh/id_rsa (RSA) 4096 SHA256:YK/qvBbZajKOe9skMvwHApA9X/M245GJfhd1kWnleNs .ssh/id_rsa.prod (RSA)
Les clés sont correctement chargées dans l’agent. OpenSSH tentera d’utiliser chacune de ces clés lors de l’authentification contre un serveur distant. Si la clé publique correspondante est configurée sur le serveur distant, l’accès sera autorisé, sans avoir à taper de mot de passe. Attention, si vous chargez un trop grand nombre de clés dans votre agent, vous risquez de tenter trop d’authentifications avant de tomber sur la bonne clé, et le serveur risque de vous déconnecter. Dans ce cas, il convient d’utiliser l’option -i pour spécifier quelle est la clé à utiliser.
Les clés sont chargées pour une durée définie. Passée cette durée, les clés expirent et doivent être rechargées avec ssh-add.
Transfert de l’agent
OpenSSH est capable de transférer votre agent lors de la connexion à une machine distante, rendant vos clés privées disponibles depuis celle-ci. Vous pouvez ensuite utiliser la machine comme rebond, et vous connecter à d’autres machines en utilisant votre clé privée, sans avoir à l’installer sur cette machine intermédiaire.
Cela se fait en utilisant l’option -A lors de la connexion SSH. Vous pouvez également configurer la directive ForwardAgent dans votre ssh_config ou ~/.ssh/config.
shell$ ssh-add -l 4096 SHA256:ZThQ6vRvCJDifvw0pzQSljane5AZBQqdAOOkNjd/HGc .ssh/id_rsa (RSA) 4096 SHA256:YK/qvBbZajKOe9skMvwHApA9X/M245GJfhd1kWnleNs .ssh/id_rsa.prod (RSA) shell$ ssh gate-ssh.foobar.com -A Welcome on gate-ssh.foobar.com, your gateway to nowhere! gate-ssh% echo $SSH_AUTH_SOCK /tmp/ssh-ymQiiUHswM/agent.23611 gate-ssh% ssh-add -l 4096 SHA256:ZThQ6vRvCJDifvw0pzQSljane5AZBQqdAOOkNjd/HGc .ssh/id_rsa (RSA) 4096 SHA256:YK/qvBbZajKOe9skMvwHApA9X/M245GJfhd1kWnleNs .ssh/id_rsa.prod (RSA) gate-ssh% ls .ssh/id_rsa ls: cannot access '.ssh/id_rsa': No such file or directory
Comme vous pouvez le constater, la clé privée n’existe pas sur le serveur « gate-ssh ». La socket définie dans $SSH_AUTH_SOCK est créée par ssh lors de la connexion, et fait appel à un tunnel SSH classique pour parler avec l’agent SSH tournant sur le client.
Néanmoins, il conviendra d’éviter de transférer son agent sur une machine en laquelle on a pas confiance, le root distant pouvant obtenir accès à vos clés privées.
