quel est le but de ssh-agent?

J'ai lu la définition officielle:

ssh-agent est un programme destiné à contenir les clés privées utilisées pour l'authentification par clé publique (RSA, DSA, ECDSA). L'idée est que ssh-agent est démarré au début d'une session X ou d'une session de connexion, et que toutes les autres fenêtres ou programmes sont lancés en tant que clients du programme ssh-agent. Grâce à l'utilisation de variables d'environnement, l'agent peut être localisé et utilisé automatiquement pour l'authentification lors de la connexion à d'autres machines à l'aide de ssh (1).

"..un programme pour contenir des clés privées .." - IMHO - les clés ssh sont générées par l'utilisateur avec la commande ssh-keygen et sont simplement et simplement stockées dans ~ / .ssh - pourquoi ai-je besoin d'un démon pour les contenir? Comment cela les tient-il exactement de toute façon - ne sont-ils pas simplement stockés dans .ssh?

"sont démarrés en tant que clients du programme ssh-agent" - je ne comprends pas. Où aurait-on besoin de ça? J'utilise généralement juste ssh comme ceci:

 ssh -i ~/.ssh/private_key_name username@hostname

Qu'entend-on exactement par manuel par "clients" - quels clients? N'exécutez pas simplement la commande ssh à partir d'un terminal pour vous connecter - quels sont les autres clients présents et pourquoi ne peuvent-ils pas simplement utiliser un chemin d'accès à ce fichier privé ssh, tout comme la commande ssh?

L'agent SSH gère pour vous la signature des données d'authentification. Lors de l'authentification sur un serveur, vous devez signer certaines données à l'aide de votre clé privée, afin de prouver que vous êtes bien.

Par mesure de sécurité, la plupart des utilisateurs protègent leurs clés privées de manière judicieuse avec une phrase secrète. Par conséquent, toute tentative d'authentification nécessiterait la saisie de cette phrase secrète. Cela peut être indésirable, donc ssh-agent met la clé en cache pour vous et vous n'avez qu'à entrer le mot de passe une fois que l'agent veut la déchiffrer (et souvent même pas, car ssh-agent peut être intégré à pam, que beaucoup de distributions font).

L'agent SSH ne remet jamais ces clés aux programmes clients, mais présente simplement un socket sur lequel les clients peuvent lui envoyer des données et sur lequel il répond avec des données signées. Un avantage supplémentaire de ceci est que vous pouvez utiliser votre clé privée même avec des programmes auxquels vous ne faites pas entièrement confiance.

Un autre avantage de l'agent SSH est qu'il peut être transféré via SSH. Ainsi, lorsque vous envoyez un message à l'hôte A et que vous transférez votre agent, vous pouvez passer de A à un autre hôte B sans avoir besoin de votre clé (même sous forme cryptée) sur l'hôte A.

L'avantage ssh-agentest qu'il vous suffit d'entrer votre phrase secrète une seule fois. Si votre clé RSA privée n'est pas chiffrée avec une phrase secrète, ssh-agent n'est pas nécessaire. La sshcommande serait un exemple de client.

Si vous vous connectez régulièrement sshà différentes machines, chacune avec sa propre clé et phrase secrète, exécuter ssh-agentvous permet de saisir la phrase secrète de chaque clé ¹ une fois au début de votre session, puis de vous authentifier autant de fois que nécessaire sur chaque machine. comme vous le souhaitez sans avoir à ressaisir votre phrase secrète.

Un autre avantage est que, conformément à la manpage, l'agent n'envoie jamais de clé privée sur son canal de requête. Par conséquent, si vous naviguez entre différentes boîtes, vos clés privées sont protégées.

¹ Vous pouvez définir la lifedurée de conservation des clés dans l'agent.

L'article Wikipedia a probablement la meilleure description:

La vérification sur le serveur est basée sur l'authentification challenge-response. SSH se connecte au serveur avec un nom d'utilisateur et la demande d'une clé. Le démon ssh obtient la demande et renvoie un défi en fonction de la clé publique stockée dans le fichier d'authentification. ssh utilise la clé privée pour construire une réponse de clé et l'envoie au sshd en attente à l'autre bout de la connexion. Il n'envoie pas la clé privée elle-même. Le démon ssh valide la réponse à la clé et, s’il est valide, accorde l’accès au système. ssh-agent simplifie cela en créant un socket qui écoute les connexions SSH. L'utilisateur démarre simplement ssh-agent en lui indiquant comment trouver leurs clés (s'ils ne se trouvent pas à l'emplacement par défaut), saisit la phrase secrète de chaque clé à utiliser, une fois pour toutes,

Encore une fois, extrait de l'article de Wikipédia:

... ssh-agent crée un socket, puis vérifie les connexions depuis ssh. Tous ceux qui peuvent se connecter à ce socket ont également accès à ssh-agent. Les autorisations sont définies comme dans un système Linux ou Unix habituel. Lorsque l'agent démarre, il crée un nouveau répertoire dans / tmp avec des autorisations restrictives. Le socket est situé dans le dossier.

Il est généralement placé dans les fichiers rc du système ou de l'utilisateur, tels que $HOME/.bashrcou $HOME/.profile(pour les shells bash), de sorte que l' ssh-agentensemble des variables d' environnement soit complètement intégré à votre environnement.

Sur mon système Fedora 14, il démarre assez tôt dans le sous-système X11. Dans ce fichier /etc/X11/xinit/xinitrc-common:

# Prefix launch of session with ssh-agent if available and not already running.
SSH_AGENT=
if [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

La variable $SSH_AGENTest ensuite utilisée dans d'autres scripts de démarrage X11 tels que ceux-ci /etc/X11/xinit/Xclients:

exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"

En l'intégrant ici, les variables d'environnement suivantes sont définies dans le cadre d'un shell parent. Par conséquent, tous les enfants forkés doivent également en disposer, par exemple:

SSH_AUTH_SOCK=/tmp/ssh-PspRF18958/agent.18958; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18959; export SSH_AGENT_PID;

Ceci est un peu plus complexe, mais en un mot c'est ce qui se passe ssh-agent.

Par exemple, dans GNOME, ssh-agentest lancé par utilisateur en tant qu’application de démarrage:

TL; DR

En bout de ligne, ssh-agentexiste, de sorte que lorsque vos clés ssh sont requises, vous ne devez les déverrouiller qu’une fois avec leur phrase secrète (en supposant qu’elles en aient une), puis elles sont disponibles sous leur forme déchiffrée en mémoire (RAM).

« sont lancés en tant que clients du programme ssh-agent » fait référence à l'idée que ssh-agent est démarré au cours (local) initialisation de la session de connexion afin que tous les programmes obtiennent les variables d'environnement $SSH_AGENT_PIDet $SSH_AUTH_SOCKqui sont nécessaires pour connecter l'agent.

Un autre avantage de la gestion de la clé privée dans ssh est que ssh-agent peut être remplacé par gpg-agent. Ainsi, vous pouvez utiliser des clés OpenPGP (avec capacité d'authentification) pour SSH. C'est une solution intéressante pour les clés OpenPGP sur une carte à puce.