[solved] Stretch SSH-Login mit gpg-key: ssh-agent abstellen

[ingo2]

Ich habe hier ein dickes Problem seit ich Stretch nutze - unter Jessie lief das alles brav:

Problem ist, daß der gpg-agent nicht beim Login startet, sobald ein anderer agent sich dafür registriert hat.
Dazu hatte ich unter Jessie
a) den gnome-keyring daemon daran gehindert mit einer Änderung:

Code: Alles auswählen

/etc/pam.d/lightdm		(disable gnome-keyring)
		-auth optional pam_gnome_keyring.so
		-session optional        pam_gnome_keyring.so auto_start
	-> geändert in
		# -auth optional pam_gnome_keyring.so
		# -session optional        pam_gnome_keyring.so auto_start

b) den ssh-agent von OpenSSL abgeschaltet mit:

Code: Alles auswählen

/etc/X11/Xsession.options
		# use-ssh-agent

c) den gpg-agent mit der Option für ssh konfiguriert:

Code: Alles auswählen

~/.gnupg/gpg-agent.conf
		enable-ssh-support

Damit hat dann der gpg-agent den ssh-login mit dem gpg-key übernommen (es ist dann egal, ob der volle Key lokal verfügbar ist oder auch vom Yubikey kommt). Bei beiden Wegen, Neuinstallation oder Upgrade Jessie->Stretch, funktioniert das alles aber nicht mehr. Immer schnappt sich der ssh-agent den Login:

Code: Alles auswählen

$ echo $SSH_AUTH_SOCK
	/tmp/ssh-NS4HO0tumlUi/agent.1076

und

Code: Alles auswählen

ssh-add -l
		The agent has no identities.

War echt verzweifelt, wie ich den ssh-agent zum Schweigen bringe.
Habe als letzten Versuch dann ganz radikal ihm das executable-bit entfernt:

Code: Alles auswählen

chmod -x /usr/bin/ssh-agent

und siehe da alles klappt wie bisher

Code: Alles auswählen

$ echo $SSH_AUTH_SOCK
	/run/user/1000/S.gpg-agent.ssh

und auch ssh-add -l zeigt den Key an.

Aber das kann ja nicht die ordentliche Lösung bei Debian (mit XPCE-Desktop) sein?
Wo muß ich da drehen, damit der ssh-agent Ruhe gibt (auch in den Startprogrammen steht er nicht)?

[smutbert]

Wusste gar nicht, dass das überhaupt möglich ist, aber wenn wir uns einmal auf das Deaktivieren des ssh-agents beschränkebn:

Hast du dich auch um /etc/xdg/autostart/gnome-keyring-ssh.desktop gekümmert (oder gnome-keyring gar nicht installiert)?
Wobei ich den Verdacht habe, dass auch die anderen /etc/xdg/autostart/gnome-keyring-*.desktop-Dateien schuld sein könnten.

Daneben gibt es noch /usr/lib/systemd/user/ssh-agent.service, das du dir ansehen

Code: Alles auswählen

$ systemctl --user status ssh-agent.service

und gegebenenfalls stoppen und deaktivieren könntest

Code: Alles auswählen

$ systemctl --user stop ssh-agent.service
$ systemctl --user disable ssh-agent.service

[ingo2]

Wusste gar nicht, dass das überhaupt möglich ist, aber wenn wir uns einmal auf das Deaktivieren des ssh-agents beschränken:

Hast du dich auch um /etc/xdg/autostart/gnome-keyring-ssh.desktop gekümmert (oder gnome-keyring gar nicht installiert)?
Wobei ich den Verdacht habe, dass auch die anderen /etc/xdg/autostart/gnome-keyring-*.desktop-Dateien schuld sein könnten.

Daran habe ich auch lange getüftelt. Der gnome-keyring ist äußerst zäh und die einzige Möglichkeit, die ich gefunden habe, den tot zu kriegen ist die oben beschiebene - aber die wirkt!

Daneben gibt es noch /usr/lib/systemd/user/ssh-agent.service, das du dir ansehen

Code: Alles auswählen

$ systemctl --user status ssh-agent.service

und gegebenenfalls stoppen und deaktivieren könntest

Code: Alles auswählen

$ systemctl --user stop ssh-agent.service
$ systemctl --user disable ssh-agent.service/usr/lib/systemd/user/graphical-session-pre.target.wants

Das reicht leider nicht. Habe es versucht mit anschließendem Reboot - hat nicht funktioniert, aber beim erneuten enablen meuterte er:

Code: Alles auswählen

$ systemctl --user enable ssh-agent.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

Und der Status sagt auch:

Code: Alles auswählen

$ systemctl --user status ssh-agent.service
● ssh-agent.service - OpenSSH Agent
   Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; static; vendor preset: enabled)
   Active: inactive (dead)

Aber die Variable $SSH_AUTH_SOCK zeigt immer noch auf ssh-agent und ssh-agent läuft immer noch:

Code: Alles auswählen

$ ps aux | grep ssh
root       812  0.0  0.0  72060  5480 ?        Ss   22:28   0:00 /usr/sbin/sshd -D
ingo      1093  0.0  0.0  17452   372 ?        Ss   22:28   0:00 /usr/bin/ssh-agent -s
ingo      1830  0.0  0.0  16988  1084 pts/0    S+   22:56   0:00 grep ssh
$ ps aux | grep gpg
ingo      1095  0.0  0.0  97928  3268 ?        SLs  22:28   0:00 /usr/bin/gpg-agent --supervised
ingo      1832  0.0  0.0  16988  1072 pts/0    S+   22:56   0:00 grep gpg

Tja, wohl ein Kollateralschaden von Systend


EDIT: bitte repariere deinen letzten geposteten befeh - der Pfad hinten dran ist zu viel.

[smutbert]

Das was mir da mit copy und paste hineingerutscht ist, enthält möglicherweise das 1.) aus der systemctl-Meldung: »/usr/lib/systemd/user/graphical-session-pre.target.wants«
(ein Link zu ssh-agent.service – nachdem die unit aber eh nicht aktiv ist, wird es das wohl auch eher nicht sein)

[ingo2]

Ach ja, noch etwas Info, warum ich die Klimmzüge mache:

Ich nutze schon eine Weile (seit Jessie) einen Yubikey für meine gpg-keys (auth, sign, decrypt). Ist somit eine 2-Faktor-Auth. Auf dem Laptop gibt's die private-keys damit nicht mehr, nur noch Stubs auf die emulierte Smert-Card.

Der Yubikey kann aber m.E. nur gpg-keys bis zu einerLänge von 4096 Bits speichern. Das oben beschriebene Szenario nutzt das dann auch gleich für den SSH-Zugang zu meinem server daheim.

Wäre toll, wenn da noch Jemand ein Kochrezept für die Nutzung des Yubikeys für OpenVPN hätte, OpenVPN braucht standardmäßig "p12-Zertifikate".

[ingo2]

So, habe die Lösung endlich gefunden Dank diesem Blog:

http://wiki.bootc.net/en/latest/gnupg/a ... h-and-xfce

Seit Stretch (und auch Buster) muß man den "ssh-agent" anders per User abschalten. Am besten ich zitiere wörtlich:

In order to use an OpenPGP smart card for SSH, the SSH_AUTH_SOCK environment variable needs to point at a GnuPG agent (gpg-agent) socket. Getting this right can be tricky.

Das habe ich ja nun erfahren

To make sure Xfce doesn’t start ssh-agent for you, you need to disable it in your settings. Unfortunately this isn’t presented anywhere in the GUI that I can find, but can be easily disabled on the command-line:

Und der erste Befehl ist die Lösung:

Code: Alles auswählen

xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false
echo use-standard-socket >> ~/.gnupg/gpg-agent.conf
echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf

Der zweite Befehl ist empfohlen (ein standard socket) und der dritte war bereits so konfiguriert.

Das Problem war, diese Unterseite zu finden - Startpage hat sie nicht indexiert und auch sonst ist die Problematik nirgends dokumentiert.

Zur Info noch:
Die Einstellung landet dann in der Datei

Code: Alles auswählen

~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml

Gruß,
Ingo