Ssh-agent sous Linux : éviter de retaper sa passphrase sans laisser traîner sa clé

Si vous utilisez une clé SSH protégée par une passphrase, vous connaissez sûrement le problème : c’est propre côté sécurité, mais vite pénible quand il faut retaper la phrase de passe à chaque connexion ou à chaque git pull. La mauvaise réponse, c’est de supprimer la passphrase de la clé. La meilleure réponse, dans beaucoup de cas, c’est ssh-agent.

ssh-agent garde la clé déverrouillée en mémoire pour votre session. Vous tapez la passphrase une fois, puis l’agent répond aux demandes SSH. C’est pratique, mais ça mérite deux précautions : vérifier quel agent est utilisé, et limiter la durée quand vous travaillez sur une machine partagée ou un serveur d’admin.

Vérifier si ssh-agent tourne déjà

Sur beaucoup de distributions Linux avec session graphique, un agent SSH est déjà lancé. En SSH pur, sur un serveur ou dans une session minimale, ce n’est pas toujours le cas. Commencez par vérifier la variable d’environnement utilisée par les outils SSH :

echo "$SSH_AUTH_SOCK"

Si la sortie est vide, votre shell ne sait pas à quel agent parler. Vous pouvez aussi regarder les clés déjà chargées :

ssh-add -l

Si vous obtenez un message du type The agent has no identities, l’agent répond bien, mais aucune clé n’est chargée. Si la commande dit qu’elle ne peut pas se connecter à l’agent, il faut en lancer un.

Démarrer ssh-agent dans votre session

Pour lancer un agent dans le shell courant, utilisez :

eval "$(ssh-agent -s)"

La commande définit les variables nécessaires, notamment SSH_AUTH_SOCK et SSH_AGENT_PID. Sans le eval, l’agent peut démarrer, mais votre shell ne récupère pas correctement son environnement. C’est le détail qui fait perdre du temps quand on teste trop vite.

Vous pouvez confirmer juste après :

echo "$SSH_AUTH_SOCK"
ps -ef | grep '[s]sh-agent'

Sur une machine personnelle, ça suffit souvent. Sur un serveur partagé, je préfère éviter de laisser un agent ouvert toute la journée sans durée limite.

Ajouter une clé SSH avec une durée limitée

Pour charger une clé classique :

ssh-add ~/.ssh/id_ed25519

Vous tapez la passphrase une fois. Ensuite, les connexions qui utilisent cette clé passent par l’agent. Pour vérifier ce qui est chargé :

ssh-add -l -E sha256

Pour limiter la durée de vie de la clé dans l’agent, utilisez -t. Exemple avec une heure :

ssh-add -t 1h ~/.ssh/id_ed25519

C’est le réglage que je préfère sur un poste d’administration. Vous gardez le confort de l’agent, mais la clé ne reste pas disponible indéfiniment si vous oubliez la session ouverte.

Tester une connexion sans retaper la passphrase

Une fois la clé chargée, testez une connexion normale :

ssh utilisateur@serveur

Si la clé correspond bien au serveur, SSH ne vous redemande pas la passphrase. Si ça échoue, relancez en mode verbeux :

ssh -v utilisateur@serveur

Vous verrez quelle clé est proposée, si l’agent répond, et où la connexion bloque. Si le problème vient plutôt du service SSH côté serveur, j’ai aussi publié un guide pour redémarrer SSH sur Ubuntu proprement et un autre pour réinstaller SSH quand il ne répond plus.

Retirer les clés de l’agent

Pour retirer une clé précise :

ssh-add -d ~/.ssh/id_ed25519

Pour vider toutes les clés chargées :

ssh-add -D

Si vous avez lancé l’agent manuellement et que vous voulez l’arrêter :

ssh-agent -k

Ne confondez pas ces commandes avec la suppression du fichier de clé dans ~/.ssh. Ici, vous retirez seulement la clé de la mémoire de l’agent.

Attention au transfert d’agent SSH

Le transfert d’agent, souvent activé avec ssh -A, permet à une machine distante d’utiliser votre agent local pour rebondir vers un autre serveur. C’est pratique dans certains environnements, mais je l’éviterais par défaut.

Si le serveur intermédiaire est compromis, votre clé privée n’est pas copiée, mais l’agent peut quand même être sollicité pendant que la session est ouverte. Pour un bastion ou une machine que vous ne contrôlez pas complètement, préférez une clé dédiée, une durée limitée, ou une configuration SSH plus stricte.

Pour garder une session longue sans perdre votre travail, screen sous Linux répond à un autre besoin : maintenir une session d’admin ouverte côté serveur. Ce n’est pas un remplacement de ssh-agent, mais les deux outils se complètent bien.

Le compromis que je garderais

Ne retirez pas la passphrase de vos clés SSH pour gagner quelques secondes. Chargez plutôt la clé dans ssh-agent, vérifiez les clés actives avec ssh-add -l, limitez la durée avec ssh-add -t quand le contexte est sensible, puis videz l’agent en fin d’intervention.

Les pages de manuel de ssh-agent, ssh-add et ssh détaillent les options disponibles. Pas besoin de tout retenir. Le point important, c’est de garder une clé protégée, mais utilisable sans transformer chaque connexion en corvée.

sudo apt update && sudo apt upgrade