ssh-agent ne se configure pas (vars env SSH_AUTH_SOCK, SSH_AGENT_PID non définis)

J'ai créé un nouveau compte utilisateur pour un ami sur Kubuntu 12.04. Quand il utilise, sshil obtient cette erreur:

Impossible d'ouvrir une connexion à votre agent d'authentification

Nous exécutons sshcertains scripts bash.

Après avoir regardé la grande variété de choses qui peuvent conduire à cette erreur, je suis tombé sur cette solution:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Il peut ensuite exécuter les sshcommandes (et les scripts bash) comme prévu.

Avant d'exécuter ces deux commandes, les variables env ne sont pas définies dans un terminal:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Après avoir exécuté les commandes, les variables env sont définies comme prévu. Cependant, ils ne restent pas définis (par exemple, dans un autre shell ou après le redémarrage).

Je veux savoir comment configurer son ordinateur pour qu'il n'ait pas à exécuter ces deux commandes pour définir les variables env. Je n'ai pas besoin de les exécuter sur mon ordinateur (jamais). Jusqu'à présent, je ne vois pas ce qui est différent entre nos machines.

Je vois ces informations dans la page de manuel, mais cela ne me dit pas comment Ubuntu configure normalement l'agent automatiquement ou ce qui se passe sur la machine de mon ami afin que cela ne fonctionne pas pour lui.

Il existe deux façons principales de configurer un agent: La première est que l'agent démarre une nouvelle sous-commande dans laquelle certaines variables d'environnement sont exportées, par exemple ssh-agent xterm &. La seconde est que l'agent imprime les commandes shell nécessaires (la syntaxe sh (1) ou csh (1) peut être générée) qui peut être évitée dans le shell appelant, par exemple eval ssh-agent -spour les shells de type Bourne tels que sh (1) ou ksh (1) et eval ssh-agent -cpour csh (1) et dérivés.

Après l'installation acctet le redémarrage, voici la sortie de lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Depuis la page de manuel:

F - commande exécutée après un fork mais sans un exec suivant

Je ne sais pas si c'est important.

Vous avez mentionné que votre utilisateur se sshconnecte et ne se connecte pas localement. Ainsi , le use-ssh-agenten /etc/X11/Xsession.optionsest un leurre: il ne sera pas exécuté sur les sessions SSH, uniquement lors de la connexion à un ordinateur de bureau GUI X11 localement (ou en utilisant une session de X11 virtuel comme sur VNC ou RDP).

Au lieu de cela, vous devez vérifier si libpam-sshest installé sur l'un ou l'autre système. Il peut être configuré pour authentifier un utilisateur à l'aide de phrases secrètes de clé privée SSH, mais cela est facultatif et vous devrez placer spécifiquement la clé ~/.ssh/login-keys.d/pour cette fonctionnalité.

Son autre fonctionnalité, cependant, consiste à démarrer automatiquement un agent SSH sur n'importe quelle session de connexion et à ajouter automatiquement des clés privées SSH à l'agent si leur phrase secrète est la même que le mot de passe de connexion de l'utilisateur. Je pense que cela pourrait être la cause du comportement différent entre vos systèmes.

Pour le

$ eval `ssh-agent -s`

construire pour fonctionner lorsqu'il est placé dans un «script de démarrage», votre session, et finalement le terminal où vous attendez l'environnement, doivent être des descendants (par forket exec) de ce script. La raison en est que la sortie de ssh-agent -s, lorsqu'elle est évaluée, définit les variables d'environnement dans l'appel du shelleval . Là-bas, ils peuvent être transmis et perdus en cours de route.

Donc, si ssh-agentest exécuté par le script A quelque part lors de la connexion, mais que le terminal B dans lequel vous démarrez votre script shell n'est pas un descendant de A, vous ne pouvez pas voir l'environnement en B.

Si vous avez ssh-agentdémarré en tant que systemd --userservice, vous devrez peut-être utiliser la convention à la place: ne laissez pas ssh-agent spécifier les variables, mais utilisez des connaissances communes lors du démarrage de l'agent et lors du démarrage de la session. Par exemple, mon ~/.config/systemd/user/ssh-agent.serviceapparence ressemble à ceci:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Et dans mon ~/.profilej'ai la ligne

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Notez que %tdans le premier correspond à ${XDG_RUNTIME_DIR}dans le second.

Remarque: je ne suis pas content de cela!

J'ai trouvé la réponse ici:

http://www.bernatchez.net/userauth.html

Sur ubuntu, l'utilitaire ssh-add ne parvient pas à charger les fichiers de certificat. Cela se produit lorsque l'agent est celui implémenté par gnome-keyring. Le correctif consiste à cesser d'utiliser le composant ssh de gnome-keyring. Étant donné que le processus d'initialisation démarre réellement un véritable agent ssh puis lance gnome-keyring-ssh.desktop qui encombre AUTH_SOCKET pour le reprendre, nous pouvons revenir à l'agent ssh d'origine en désactivant gnome-keyring-ssh.desktop.

Désactivez gnome-keyring-ssh.desktop:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Ajoutez la ligne suivante au fichier du bureau et enregistrez-la, puis redémarrez:

X-GNOME-Autostart-enabled=false

Vous avez mentionné que

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

fonctionne comme vous le souhaitez. Il vous suffit donc de les exécuter au bon moment, dans .bash_profile ou .xsession. Ajoutez des instructions de débogage comme (date; env|sort) >> /tmp/logpour vous aider à comprendre exactement quand elles s'exécutent.