it-swarm.com.de

Warum kann ich nicht mit meinem ssh-Agenten interagieren? (z. B. 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-add -Befehle zu ignorieren. Schauen Sie sich das unten an und Sie werden sehen, was ich meine.

  1. Listet 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 [email protected] (RSA)
    

    Dieser Schlüssel wird beim Booten geladen, aber ich habe einen ECDSA-Schlüssel erwartet, nicht 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 [email protected] (RSA)
    

    Was zur Hölle? Es liegt nur an mir.

  3. Was ist 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üsselbund auf meinem KDE-System? Sollte die KDE-Brieftasche 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 (von Puppet verwaltet).

7
gertvdijk

HINWEIS: Dies ist keine Antwort auf das Grundproblem. Bitte geben Sie eine neue Antwort, wenn Sie der Meinung sind, dass Sie die Grundursache beheben können. Man muss wirklich nachlesen, warum meine Lösung nur ein hässlicher Hack ist.


Hier finden Sie eine Erklärung dazu, was beim Booten passiert, um den Täter 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 Sitzungen auswählen . Das Verzeichnis /usr/share/xsessions enthält die Dateien für jede dieser installierten Desktop-Umgebungen, und Ihre benutzerspezifische Auswahl wird in ~/.dmrc gespeichert.

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

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

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

Alle Skripte prüfen zuerst die Umgebungswerte, ob sie fortfahren werden. Z.B.

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

Dies macht es zu einer Art Rennbedingung, dass der SSH-Agent tatsächlich gestartet wird. Erster gewinnt. Machen Sie sich bereit für noch schlimmere Dinge.

Wie kommt es, dass es auf einer Maschine zuverlässig funktioniert und nicht zuverlässig bei einem anderen? Die X-Sitzungs-Upstart-Jobs werden nur gestartet, wenn die Umgebungsvariable DESKTOP_SESSION in /etc/upstart-xsessions, die von /etc/X11/Xsession.d/00upstart verarbeitet wird, für sie in die Whitelist aufgenommen wurde. Mit KDM kann eine Desktop-Umgebung als "Standard" (default in ~/.dmrc) festgelegt werden, effektiv kde-plasma, jedoch nicht kde-plasma.

Mit Session=kde-plasma:

⟫ echo $DESKTOP_SESSION
kde-plasma

Mit Session=default in einem KDE-Plasma-Desktop:

⟫ echo $DESKTOP_SESSION
default

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

Schnellkorrektur für die Ausführung einer 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 anderer Fehler verhindert die ordnungsgemäße Verbindung mit dem GNOME-Schlüsselring-SSH-Agenten (oder ssh-add sollte sich beschweren und fehlschlagen). Oh, ich hasse dich, Käfer.

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

Im Moment habe ich beschlossen, nur den Upstart-Fehler zu verwenden und zu verhindern, dass Upstart-Sitzungsaufträge ausgeführt werden, indem ich Session=default setze. Ich bin mir nicht sicher, wie sehr dies bricht, aber bisher habe ich noch nichts auseinanderfallen sehen.

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

6
gertvdijk

Ich lande immer Sudo apt-get remove --purge gnome-keyring ohnehin 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.

2
kaleissin

Mir ist klar, dass dies ein alter Faden ist. Ich benutze xubuntu 16.04. Scheint, der Bug ist immer noch da. Ich habe Seepferdchen installiert, um die Schlüssel zu verwalten, und das hat funktioniert.

1
VGR