Warum kann ich nicht mit meinem SSH-Agenten interagieren? (zB ssh-add -D funktioniert nicht)

Auf meinem Kubuntu 14.04-System versuche ich, Schlüssel mit meinem SSH-Agenten zu verwalten, aber irgendwie scheint es, meine ssh-addBefehle zu ignorieren . Schauen Sie sich das unten an und Sie werden sehen, was ich meine.

1. Listen Sie die aktuellen Schlüssel auf

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

   Dieser Schlüssel wird beim Booten geladen, aber ich habe einen ECDSA-Schlüssel erwartet, keinen RSA. Ich kenne diesen Schlüssel nicht ...

2. Entfernen Sie den Schlüssel vom Agenten.

   ⟫ ssh-add -D
   All identities removed.
   

   yey! Aber ist es?

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

   Was zum Teufel? Es lügt mich einfach an.

3. Was ist denn hier los?

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

   Mal sehen, welcher Prozess diesen Socket ausführt.

   ⟫ 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 [...]
   

   Was zum Teufel macht der GNOME-Schlüsselring auf meinem KDE-System? Sollte KDE Wallet hier nicht mein SSH-Agent sein?

Dies führt zu mehr Fragen als Antworten und ich habe einen nicht funktionierenden SSH-Agenten.

Auf einem anderen System beobachte ich dieses Verhalten nicht und finde keinen Konfigurationsunterschied. Beide haben nur KDE installiert und die installierten Pakete sind nahezu identisch (verwaltet von Puppet).

HINWEIS: ist keine Antwort zur Lösung des Grundproblems. Bitte geben Sie eine neue Antwort, wenn Sie der Meinung sind, dass Sie die Grundursache lösen können. Sie müssen wirklich lesen, warum meine Lösung nur ein hässlicher Hack ist.

Hier ist eine Erklärung, was beim Booten passiert, um den Schuldigen zu identifizieren.

Wenn Sie KDM (oder LightDM) als Anmeldemanager verwenden, wird beim Anmelden eine X-Sitzung für Sie erstellt. Mit dem Anmeldemanager können Sie eine X-Sitzung (z. B. GNOME, KDE Plasma usw.) basierend auf den in Ihrem System verfügbaren auswählen . Das Verzeichnis /usr/share/xsessionsenthält die Dateien für jede dieser installierten Desktop-Umgebungen, und Ihre benutzerspezifische Auswahl wird in gespeichert ~/.dmrc.

Während die Desktop-Umgebung nach dem Anmelden geladen wird, werden alle Skripts geladen /etc/X11/Xsession.d/. Auf einem Kubuntu 14.04-System wird /etc/X11/Xsession.d/90x11-common_ssh-agentdort standardmäßig ein SSH-Agent initialisiert. Wie erwartet. Großartig!

In der Praxis sehen wir jedoch verschiedene Dinge. Woher kommt gnome-keyring-daemondann und warum wird der reguläre ssh-agentnicht gestartet? Nun, der GNOME-Schlüsselring wird auf zwei Arten gestartet:

• XDG-Autostart, in /etc/xdg/autostart/gnome-keyring-ssh.desktop
• Als Upstart- Sitzungsjob in/usr/share/upstart/sessions/gnome-keyring.conf

Alle Skripte prüfen zunächst die Umgebungswerte, ob sie fortgesetzt werden. Z.B

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

Dies macht es zu einer Art Rennbedingung, bei der der SSH-Agent tatsächlich gestartet wird. Der erste gewinnt. Machen Sie sich auf böse Dinge gefasst.

Wie kommt es, dass es an einer Maschine zuverlässig funktioniert und an einer anderen nicht zuverlässig ? Die X-Session-Upstart-Jobs werden nur gestartet, wenn die DESKTOP_SESSIONUmgebungsvariable für sie in der Whitelist aufgeführt ist /etc/upstart-xsessionsund von verarbeitet wird /etc/X11/Xsession.d/00upstart. Mit KDM kann eine Desktop-Umgebung "Standard" ( defaultin ~/.dmrc) festgelegt werden kde-plasma, die jedoch nicht angezeigt wird kde-plasma.

Mit Session=kde-plasma:

⟫ echo $DESKTOP_SESSION
kde-plasma

Mit Session=defaultin einem KDE Plasma Desktop:

⟫ echo $DESKTOP_SESSION
default

Das ist einfach falsch. Und Sie können jetzt erraten, warum die Whitelist-Prüfung fehlschlägt /etc/upstart-xsessions.

Schnelle Lösung zum Ausführen der Terminalsitzung

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

Fazit

Es scheint, dass man einen Fehler finden kann, wenn alle Upstart-Sitzungsjobs überhaupt nicht gestartet werden. Ein weiterer Fehler verhindert die ordnungsgemäße Verbindung mit dem SSH-Agenten des GNOME-Schlüsselbunds (oder ssh-addsollte sich beschweren und fehlschlagen). Oh, ich hasse dich, Käfer.

Sobald ich Zeit finde, nachzuforschen, was genau was tun soll, werde ich die Fehlerberichte einreichen.

Im Moment habe ich beschlossen, nur den Upstart-Fehler zu verwenden und zu verhindern, dass Upstart-Sitzungsjobs durch Festlegen ausgeführt werden Session=default. Ich bin mir nicht sicher, wie viel das bricht, aber bisher habe ich nichts auseinander fallen sehen.

Die Hauptursache ist in erster Linie das Auftreten des GNOME-Schlüsselbunds, der mich nicht anlügen und weiterhin falsche Schlüssel anbieten sollte.

Ich lande sowieso immer sudo apt-get remove --purge gnome-keyring , gefolgt von einem Neustart. ubuntu-sso hängt davon ab, aber ich benutze das nicht, also keine Sorge.

ssh-agent scheint danach einfach so zu funktionieren, wie es sollte.

Mir ist klar, dass dies ein alter Thread ist. Ich benutze xubuntu 16.04. Der Fehler scheint immer noch da zu sein. Ich habe Seepferdchen installiert, um die Schlüssel zu verwalten, und das hat funktioniert.