Ich hab vor einiger Zeit von ArchLinux auf debian gewechselt. Danach fiel mir auf, dass wenn ich pass nutze und danach SSH, ich zweimal die PIN für den Yubikey eingeben muss. Außerdem hat manchmal pass nicht funktioniert, wenn ich es nach SSH aufgerufen hab (da wurde dann die “GPG-Smartcard” (der Yubikey) gar nicht gefunden). Da war dann die Lösung den Yubikey einmal neu zu stecken und danach pass vor SSH aufzurufen.
Auffällig war, dass nach dem pass-Aufruf immer ein zweiter gpg-agent lief. Ich hab mir eine zeitlang damit beholfen in die ~/.gnupg/scdaemon.conf pcsc-shared zu schreiben -
damit ist der Yubikey nicht exklusiv von einem der beiden gpg-agents blockiert, aber nach dem Update auf trixie ist noch irgendwas anderes schief (dazu in einem anderen Blogpost mehr),
so dass ich bei jedem Zugriff auf den Yubikey die PIN eingeben muss. Also musste ich mal das eigentliche Problem lösen.
Also mal Yubikey angesteckt, eine SSH-Verbindung aufgebaut und danach pass aufgerufen. Es wird ein zweiter gpg-agent gestartet und der pass-Aufruf funktioniert nicht. Soweit kennen wir das ja schon.
Das googlen nach den Parametern, mit denen der gpg-agent gestartet wird (--use-standard-socket --daemon) hat mich dann zumindest drauf gebracht, dass er wohl mittels gpgconf --launch gpg-agent gestartet wird,
hat sonst aber wenig Erkenntnisse gebracht.
Dann also mal strace auf den pass-Aufruf geschmissen und das große Wundern geht los: Wieso wird der gpg-agent-socket in /run/user/1000/gnupg/d.4wrkznjfxmhuw5861gsoydhj/S.gpg-agent gesucht, wenn doch
die systemd-User-Unit %t/gnupg/S.gpg-agent als Pfad vorgibt (was /run/user/1000/gnupg/S.gpg-agent ist).
Nach einigem Googlen nach der Frage wie man den Ort des Sockets anpassen kann, bin ich auf https://gnupg-users.gnupg.narkive.com/1JY1lXWm/change-agent-socket-path gestoßen wo ich folgenden Absatz fand:
If you use a GNUPGHOME different from ~/.gnupg gpg will not connect
to /run/user/1000/gnupg but to /run/user/1000/gnupg/SOMEDIR/. That dir
is not created on the fly but requires that the user creates it in
advance. SOMEDIR is the hash of GNUPGHOME and gpgconf has a command to
compute that hash and create the directory.
Ich hatte mir irgendwann im Rahmen von mein Homedir soll schöner werden überlegt, dass ich ~/.gnupg lieber in ~/.config/gnupg
haben will und hab in meiner .xinitrc, .xprofile und .zshrc export GNUPGHOME="${XDG_CONFIG_HOME}/gnupg" gesetzt.
Ich hatte außerdem einen Symlink gesetzt (von ~/.gnupg nach ~/.config/gnupg). D.h. eigentlich wäre die Umgebungsvariable auch gar nicht nötig gewesen…
Was ist also passiert: Der von systemd gestartete gpg-agent war für SSH zuständig (das hat auch funktioniert, da der SSH-agent über die Umgebungsvariable SSH_AUTH_SOCK bekannt gemacht wird
(und nicht über komische Regeln)). Wenn ich aber gpg genutzt habe, hat es festgestellt, dass kein gpg-agent an dem angenommenen Unix-Socket lauscht und hat kurzerhand einen neuen gestartet
(weil es für Smartcards (Yubikey) nötig ist, dass einer läuft).
Die Lösung: Ausgiebig ge-face-palmt, die GNUGPGHOME-Einträge aus den Dateien entfernt und ein reboot später war alles tuffi und
funktioniert so wie es soll.