Comment puis-je résoudre ce problème d'agent ssh?

17

J'utilise Linux Mint, et je n'ai pas pu obtenir le gnome-keyring pour le déverrouiller automatiquement lors de la connexion, semble-t-il.

Un symptôme de mon problème est le suivant:

$ ssh-add
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)

$ git pull
WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-Nmf3J3/pkcs11: No such file or directory

Comment puis-je faire en sorte que git puisse pousser / tirer sans aucune entrée de phrase secrète de ma part?

Je me rends compte qu'il y a plusieurs choses ici avec gnome-trousseau de clés et ssh-agent, mais je n'ai pas réussi à le résoudre.

L'exécution ssh-addpendant une session signifie que l'on ne me demande plus ma phrase secrète pour SSH / git.

Le problème est que je devrais exécuter ssh-addpendant chaque session - je dois savoir comment faire pour déverrouiller le trousseau de clés de Gnome à la connexion.

$ export | grep GNOME          
GNOME_KEYRING_CONTROL=/tmp/keyring-hjMM4V
GNOME_KEYRING_PID=1961

Cela s'est produit à nouveau au cours de la même session que le premier montage. Je l'ai fait git pullet je l'ai eu WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-hjMM4V/pkcs11: No such file or directory.

$ env | grep SSH
SSH_AGENT_PID=2116
SSH_AUTH_SOCK=/tmp/ssh-OACxJMBY2038/agent.2038

$ ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
eoin      2116  2038  0 09:47 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
eoinoc
la source
1
Pouvez-vous exécuter export | grep GNOMEet publier les résultats. Avez-vous vu ce bug?
didster
Ressemble à un bug pertinent. Étant donné que je ne vois pas toujours l'avertissement, je ne sais pas si j'ai un problème plus simple à simplement gnome-keyringdéverrouiller automatiquement à la connexion.
eoinoc
vous avez peut-être un autre agent que gnome-keyring en cours d'exécution. Qu'en est-il env | grep SSHetps -fp $SSH_AGENT_PID
Stéphane Chazelas
@StephaneChazelas J'ai ajouté ce que vous avez suggéré, merci. Oui, j'ai rendu la vie complexe avec zshet en tmuxcours d'exécution (juste pour le mentionner).
eoinoc

Réponses:

2

Ce qui doit arriver, c'est:

Vous démarrez une session gnome, dont un démon gnome-keyring (qui agit également comme un agent ssh) démarre et l'environnement de tout ce qui a démarré pendant cette session gnome est mis à jour avec des informations sur la façon de contacter cet agent ssh. Le mot de passe que vous fournissez lors de la connexion graphique est utilisé pour déverrouiller le trousseau de clés par défaut.

Lorsque vous utilisez gnome-keyring comme ssh-agent, vous ne voulez pas utiliser un autre agent comme ssh-agent.

Lorsque votre session X se termine, gnome-keyring fait de même. Mais votre session tmux reste. Ensuite, même si vous démarrez un autre gnome-keyring ou ssh-agent, l'environnement des processus déjà démarrés par tmuxne pourra pas lui parler à moins que vous ne mettiez à jour leur environnement avec le chemin du nouveau socket.

Ce que vous pourriez faire, c'est:

gnome-keyring-daemon -r > ~/.gkr

Et faites . ~/.gkrdans tous les shells que vous souhaitez utiliser le nouveau gnome-keyring

Attention cependant à l'AFFICHAGE auquel gnome-keyring-daemon va se connecter.

Stéphane Chazelas
la source
Voulez-vous dire que ce n'est que lorsque ma session X se termine, en d'autres termes chaque fois que je me déconnecte et me reconnecte? Je n'ai pas .gkr, devrais-je? Comment savoir à quel écran gnome-keyring-daemonva se connecter?
eoinoc
2

La première chose que j'essaierais, apt-get install ssh-askpass-gnomesinon, si vous n'avez pas ce paquet (ou un autre programme askpass) installé, alors gnome ne peut pas vous demander votre mot de passe lorsque vous devez déverrouiller votre clé.

Vous devrez également DISPLAYdéfinir correctement votre variable:

$ echo $DISPLAY
:0.0

Aussi, comment démarrez-vous votre terminal? Il peut y avoir un problème avec la façon dont vous démarrez la session de terminal et si elle hérite ou non gnome-session. Cela peut se produire lorsque vous utilisez un programme gnon-gnome pour définir vos raccourcis clavier.

En supposant que vous utilisez, gnome-terminalvous pouvez vérifier en utilisant pstree. Ici, vous pouvez voir l'héritage correct se produire:

$ pgrep gnome-terminal | xargs -l1 pstree -s 
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───xmonad-x86_64-l(27139)───gnome-terminal(26036)─┬─bash(26041)
                                                                                                                 ├─gnome-pty-helpe(+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 ├─{gnome-terminal}+
                                                                                                                 └─{gnome-terminal}+

Alors que dans cette session, il n'hérite PAS de gnome-session:

$ pgrep gnome-terminal | xargs -l1 pstree -s 
init(1)───sh(25919)───gnome-terminal(25920)─┬─bash(25927)
                                            ├─gnome-pty-helpe(25926)
                                            ├─{gnome-terminal}(25921)
                                            ├─{gnome-terminal}(25924)
                                            └─{gnome-terminal}(25928)

Vérifiez également que le ssh-agentdémarrage est effectué par gnome-session:

$ pgrep ssh-agent | xargs -l1 pstree -s
init(1)───lightdm(1643)───lightdm(26912)───gnome-session(27049)───ssh-agent(27091)
aculich
la source
C'est un peu compliqué de savoir quel terminal j'utilise (ma faute!). Ma commande de lancement de terminal est mate-terminal --maximize -e tmux(que je présume être gnome-terminal). En outre, zshest ensuite chargé à l'intérieur tmux. ssh-askpass-gnomeetait installé. $DISPLAYa le résultat attendu. Pour l'héritage, tmuxest assis sous mate-terminalsans mension de gnome-session. Sur une branche distincte, c'est tmux───zsh───xargs───pstree. Pour répondre à votre dernière question, la sortie est: init───mdm───mdm───x-session-manag───ssh-agent. Qu'est-ce que tu penses? Merci.
eoinoc
eh bien, en supposant que vous utilisez gnome (et je pense que Mint le fait par défaut, donc à moins que vous ne l'ayez changé par défaut?), alors je pense que ne pas avoir votre mate-terminalhéritage gnome-sessionest le problème. deux questions: 1) quel est le résultat de pgrep -fl gnome-sessionet; 2) Quelle action prenez-vous pour appeler réellement votre terminal? à partir d'un menu? à partir d'une liaison de raccourci clavier? ou ????
aculich
Oui, je suis sur Gnome. 1) La sortie est vide. 2) Très intéressant. Je fais d'habitude Ctrl+Alt+t. C'est un raccourci que j'ai défini en utilisant l'application Linux Mint en Keyboard Shortcutsutilisant la commande que j'ai mentionnée précédemment. Cependant , lors du lancement Terminalvia le menu principal "Démarrer", SSH a agi différemment . L'interface graphique Gnome m'a demandé mon mot de passe pour mon trousseau de clés. L'option d'enregistrement de cette phrase secrète pour les sessions ultérieures était grisée, je n'ai pas pu la sélectionner. (La commande du lanceur de menu l'est également mate-terminal --maximize -e tmux.) Cela nous rapproche-t-il? Merci, aculich.
eoinoc
Si vous voyez le comportement étrange avec celui Ctrl+Alt+tque vous avez défini dans les raccourcis clavier, je pense que vous rencontrez probablement un bogue dans mdm / MATE. Quelle version de Mint utilisez-vous?
2012
Je suis une version derrière, sur Linux Mint 13. Mais pour le terminal accessible par menu, pourquoi ne me laisserait-il toujours pas sélectionner "enregistrer cette phrase secrète pour chaque fois que je me connecte"?
eoinoc
1

Je pense que le problème sur le stockage permanent de la clé SSH protégée par mot de passe.

Veuillez consulter les ressources suivantes:

Md Mahbubur Rahman
la source
Je commenterai au fur et à mesure. Avec le premier lien, j'ai ajouté `IdentityFile ~ / .ssh / id_rsa` à ~/.ssh/configmais cela ne l'a pas corrigé .
eoinoc
Le troisième lien montre une configuration de base qui ne semble pas aller plus loin que ce que j'ai déjà fait. Merci quand même.
eoinoc
-1

Ajoutez ceci à votre .bash_profile

if [ -n "$SSH_AUTH_SOCK" \
    -a "${SSH_AUTH_SOCK::13}" = "/tmp/keyring-" \
    -a ! -L "$SSH_AUTH_SOCK" ]
then
    OLD_AUTH_SOCK="$SSH_AUTH_SOCK"
    eval `ssh-agent`
    mv "$OLD_AUTH_SOCK" "$OLD_AUTH_SOCK"~
    ln -sfn "$SSH_AUTH_SOCK" "$OLD_AUTH_SOCK"
    SSH_AUTH_SOCK="$OLD_AUTH_SOCK"
fi
Mark Cohen
la source
Merci Mark. Avec cela, $SSH_AUTH_SOCKa une valeur de /tmp/ssh-QCndYkdq2025/agent.2025. Suis-je en train de manquer quelque chose? $git pullfait toujours apparaître l'invite de phrase secrète SSH.
eoinoc
Vérifiez vos autorisations sur votre fichier .ssh / authorized_keys sur le serveur. Il devrait être 06h00.
Mark Cohen
Sur le serveur? GitHub est le serveur externe et ma clé SSH y est enregistrée. N'est-ce pas plutôt un problème local, non?
eoinoc
Désolé, je n'avais pas réalisé que vous utilisiez github. Oui, vous n'avez aucun contrôle sur cet hôte. Vous pouvez ajouter plusieurs clés à votre agent ssh et expérimenter le sshing sur localhost pour vous assurer que vous pouvez authentifier correctement. En outre, vous pouvez essayer ssh -vvv user @ host et voir ce qui se casse.
Mark Cohen
La plupart des systèmes Linux de bureau (Mint inclus) se comportent ssh-agentcorrectement lors de la connexion dès la sortie de la boîte et ce sont généralement des choses comme vous qui le cassent. Si pour une raison quelconque votre système ne gère pas ssh-agent, ne le faites pas à la main. Utilisez plutôt un trousseau qui est bien conçu pour gérer cela et les problèmes connexes. Il fonctionne également pour BSD (Mac) et d'autres systèmes non Linux.
aculich