web-dev-qa-db-fra.com

Pourquoi ne puis-je pas interagir avec mon agent ssh? (par exemple, ssh-add -D ne fonctionne pas)

Sur mon système Kubuntu 14.04, j'essaie de gérer les clés avec mon agent SSH, mais il semble ignorer mes commandes ssh-add. Regardez ceci ci-dessous et vous verrez ce que je veux dire.

  1. Lister les clés actuelles

    ⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)

    Cette clé est chargée au démarrage, mais je m'attendais à une clé ECDSA, pas à RSA. Je ne connais pas cette clé ...

  2. Retirez la clé de l'agent.

    ⟫ ssh-add -D
All identities removed.

    oui! Mais ... c'est ça?

    ⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)

    Que se passe-t-il? C'est juste pour moi.

  3. Que se passe t-il ici?

    ⟫ env | grep -i ssh
SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/ssh

    Voyons quel processus exécute ce socket.

    ⟫ Sudo fuser -u /run/user/1000/keyring-eDJggO/ssh
[Sudo] password for gert: 
/run/user/1000/keyring-eDJggO/ssh:  9434(gert)
⟫ ps -p 9434 u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
gert      9434  0.0  0.0 292528  7192 ?        Sl   00:05   0:00 gnome-keyring-daemon [...]

    Que fait le trousseau de clés GNOME sur mon système KDE? Le portefeuille KDE ne devrait-il pas être mon agent SSH ici?

Cela conduit à plus de questions que de réponses et je reste avec un agent ssh non fonctionnel.

Sur un autre système, je n'observe pas ce comportement et je ne parviens pas à trouver une différence de configuration. Seuls les deux ont KDE installé et les paquets installés sont presque identiques (gérés par Puppet).

sshkubuntukdegnome-keyringssh-agent
7
gertvdijk

REMARQUE: n’est pas une réponse à la résolution du problème fondamental. Veuillez fournir une nouvelle réponse si vous pensez pouvoir résoudre le problème à la racine. Vous devez vraiment comprendre pourquoi ma solution est juste un vilain bidouillage.

Voici une explication de ce qui se passe au démarrage, identifiant le coupable.

En utilisant KDM (ou LightDM) comme gestionnaire de connexion, une session X est créée pour vous lors de la connexion. Le gestionnaire de connexion vous permet de sélectionner une session X (par exemple GNOME, KDE Plasma, etc.) en fonction de celles disponibles sur votre système. . Le répertoire /usr/share/xsessions contient les fichiers de chacun des environnements de bureau installés et votre choix spécifique à l'utilisateur est enregistré dans ~/.dmrc.

Tandis que l'environnement de bureau se charge après la connexion, il charge tous les scripts dans /etc/X11/Xsession.d/. Sur un système Kubuntu 14.04, j’y vois /etc/X11/Xsession.d/90x11-common_ssh-agent par défaut, initialiser un agent SSH. Comme prévu. Génial!

En pratique cependant, nous voyons des choses différentes. D'où vient alors gnome-keyring-daemon et pourquoi le ssh-agent normal n'est-il pas démarré? Eh bien, le trousseau de clés GNOME est démarré de deux manières:

  • Démarrage automatique XDG, dans /etc/xdg/autostart/gnome-keyring-ssh.desktop
  • En tant que Upstart travail de session dans /usr/share/upstart/sessions/gnome-keyring.conf

Tous les scripts vérifient d’abord les valeurs de l’environnement s’ils vont continuer. Par exemple.

[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }

Cela en fait une sorte de condition de concurrence pour laquelle l'agent SSH est réellement démarré. Le premier gagne. Préparez-vous pour plus de méchants morceaux.

Comment cela fonctionne-t-il sur une machine de manière fiable et sans de manière fiable à un autre? Les travaux upstart de session X ne sont démarrés que lorsque la variable d'environnement DESKTOP_SESSION figure dans sa liste blanche dans /etc/upstart-xsessions, gérée par /etc/X11/Xsession.d/00upstart. KDM permet de définir un environnement de bureau 'Par défaut' (default dans ~/.dmrc), effectivement kde-plasma, mais n'apparaissant pas kde-plasma.

Avec Session=kde-plasma:

⟫ echo $DESKTOP_SESSION
kde-plasma

Avec Session=default sur un bureau KDE Plasma:

⟫ echo $DESKTOP_SESSION
default

C'est tout simplement faux. Et vous pouvez maintenant deviner pourquoi la vérification de la liste blanche échoue contre /etc/upstart-xsessions.

Solution rapide pour l'exécution d'une session de terminal

killall gnome-keyring-daemon && eval `ssh-agent`

Conclusion

Il semble que l'on puisse frapper un bogue avec tous les travaux de session Upstart non démarrés. Un autre bogue empêche une interfaçage correcte avec l'agent SSH de GNOME (ou ssh-add devrait se plaindre et échouer). Oh je te déteste, les insectes.

Une fois que j'ai trouvé le temps de faire des recherches sur ce qui est exactement censé faire quoi, je vais déposer les rapports de bogues.

Pour le moment, j'ai décidé de simplement "utiliser" le bogue Upstart et d'empêcher l'exécution des travaux de session Upstart en définissant Session=default. Je ne sais pas à quel point cela se casse, mais jusqu'à présent, je n'ai rien vu s'effondrer.

La cause fondamentale est l'apparition du trousseau de clés GNOME, ce qui ne devrait pas me mentir et continuer à offrir de mauvaises clés.

6
gertvdijk

Je finis toujours par Sudo apt-get remove --purge gnome-keyring quand même, suivi d'un redémarrage. Ubuntu-sso en dépend, mais je ne l'utilise pas, alors ne vous inquiétez pas.

ssh-agent semble fonctionner comme il se doit par la suite.

2
kaleissin

Je réalise que c'est un vieux fil. J'utilise xubuntu 16.04. Semble que le bogue est toujours là. J'ai installé l'hippocampe pour gérer les clés et cela a fonctionné.

1
VGR