SSH Security Keys

[Jayskie]

Hallo Zusammen,

ich habe gerade mein Laptop mit Debian 12 frisch aufgesetzt und stehe (mal wieder) vor einem sehr lästigen Problem.
Ich nutze primär Yubikeys für Hardwaregestützte SSH Schlüssel, mit PIN und User Presence.

Wann immer ich versuche, mich nun mit einem solchen Key zu authentifizieren bekomme ich die Fehlermeldung

Code: Alles auswählen

$ ssh -T git@gitlab.com
sign_and_send_pubkey: signing failed for ED25519-SK "/home/jayskie/.ssh/id_ed25519_sk_rk_jayskie" from agent: agent refused operation
git@gitlab.com: Permission denied (publickey).

Wieso verweigert der SSH Agent die Arbeit? -> Weil die PIN Abfrage (ssh-askpass) nicht durchgeführt wird und somit nicht erfolgreich mit dem Yubikey kommuniziert wird.
Ich habe dieses Problem in der Vergangenheit bereits zweimal gelöst - die letzte Lösung ist leider mit dem alten Laptop gestorben, da ist nichts zu rekonstruieren.

Googlefu bringt in dieser Hinsicht leider nichts zutage, bis auf einen unschönen Würgaround:

Code: Alles auswählen

$ eval "$(ssh-agent -s; SSH_ASKPASS=/usr/bin/ssh-askpass)"

Einmal ausgeführt kann ich infolge das aktuelle Terminal verwenden, leider erzeuge ich damit jedes Mal einen neuen ssh-agent Prozess.

Mir ist relativ klar dass das Problem darin beruht dass der ssh-agent nicht auf ssh-askpass zurückgreift - Mein Setup ist eine ganz einfache Debian 12, Gnome 43 Kiste.
Aktiv sind ein gcr-ssh-agent als wrapper und ein ssh-agent User Service.

Seahorse (gcr-ssh-agent) liefert ein graphisches ssh-askpass (unter /usr/libexec/seahorse/ssh-askpass), zusätzlich habe ich ssh-askpass aus den Repositories installiert (unter /usr/bin/ssh-askpass).

Die Preisfrage lautet: Wie bekomme ich dem ssh-agent User Service beigebogen wo er das askpass findet?
Anpassung der Service File hat schonmal nichts geholfen

[Jayskie]

Okay ich habe einen Fix gefunden

Code: Alles auswählen

export SSH_AUTH_SOCK=/run/user/1000/gcr/ssh

Mit angepasstem SSH_AUTH_SOCK Pfad läuft die Abfrage wie geschmiert.
Muss nur noch feststellen, wo ich diese Anpassung in den Agent Service reinbiege (aktuell habe ich die .zshenv erweitert, somit sind graphische Programme weiterhin borked)

Ich bin auf diesen Beitrag gestoßen, der lustigerweise das Gegenteil von dem beschreibt, was ich festgestellt habe https://serverfault.com/a/1156987 (oder mein Sprachverständnis schwächelt).
Wie stelle ich am einfachsten fest, an welcher Stelle meine Shell den falschen Wert für die Umgebungsvariable SSH_AUTH_SOCK bekommt?