Hi, from the README: |Since 2.1.17, users on machines with systemd will have their gpg-agent |process launched automatically by systemd's user session, upon first |access of any of the expected gpg-agent sockets (including the ssh |socket). systemd will also cleanly tear this process down at session |logout. I find that inacceptable at least for system accounts. The suggested remedy is to manually mask four systemd units inside every single account. Please consider adding a global option to start gpg-agent only for whitelisted accounts. There should also be an option to start gpg-agent for normal users, that might default to yes, but it should be possible to turn it off. Greetings Marc
[...] Hello Marc, I am a little bit too slow right now to wade through systemd's documentation but afaiui systemd's user sessions happen on login, which usually is disabled for system accounts. cu Andreas
It, for example, happens for the account that my ansible is running against. Greetings Marc
Hello, just to clarify: we are not starting gpg-agent automatically on login. We are shipping systemd user session units to lauch gpg-agent under systemd's monitoring when gpg *needs* an agent. The other way to do this is to let gpg itself start a gpg-agent as a long running daemon the first time it needs it. If your ansible service ends up starting gpg-agent it is probably invoking gpg in way that needs gpg-agent. gpg-agent is not an optional component of the gnupg toolsuite. Why do you find it inacceptable to run gpg-agent under systemd control in your usage scenario? cu Andreas
It is probably enough to have an ssh-agent running on the side of the ssh client to invoke a gpg agent on the server side? I am not using gpg in any way here. Greetings Marc
If we were to remove the systemd sockets, then gpg would auto-launch the
daemons on its own.
So maybe the issue is that the gpg-agent-ssh.socket startup is somehow
setting SSH_AUTH_SOCK when it shouldn't be?
Marc, what does this command show for you?
gpgconf --list-options gpg-agent | grep ^enable-ssh-agent:
Can you see anything in the per-user journal for the system user related
to gpg-agent? as the system user in question, can you share the output
of this:
journalctl --user-unit 'gpg-agent*'
Regards,
Would ConditionUser=!@system be an option here for those user services? https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#ConditionUser=
Nothing.
Apr 12 09:36:53 spinturn systemd[1193]: Listening on gpg-agent-browser.socket - GnuPG cryptographic agent and passphrase cache (access for web browsers).
Apr 12 09:36:53 spinturn systemd[1193]: Listening on gpg-agent-extra.socket - GnuPG cryptographic agent and passphrase cache (restricted).
Apr 12 09:36:53 spinturn systemd[1193]: Starting gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation)...
Apr 12 09:36:53 spinturn systemd[1193]: Starting gpg-agent.socket - GnuPG cryptographic agent and passphrase cache...
Apr 12 09:36:53 spinturn systemd[1193]: Listening on gpg-agent-ssh.socket - GnuPG cryptographic agent (ssh-agent emulation).
Apr 12 09:36:53 spinturn systemd[1193]: Listening on gpg-agent.socket - GnuPG cryptographic agent and passphrase cache.
[12/4999]mh@spinturn:~ $
The timestamps from that roughly correlate with the last reboot of that
machine. And this is also the timestmap of the systemd unit stamp files
in /run:
$ sudo ls -al /run/user/1001/systemd/units/
total 0
drwxr-xr-x 2 mh mh 80 Apr 12 09:36 .
drwxr-xr-x 5 mh mh 140 Apr 12 09:36 ..
lrwxrwxrwx 1 mh mh 32 Apr 12 09:36 invocation:gpg-agent.socket -> c01418222288497ba5ab36a4314f6abe
lrwxrwxrwx 1 mh mh 32 Apr 12 09:36 invocation:gpg-agent-ssh.socket -> 62deedfe57c94f4eb52cccf850840512
[29/5010]mh@spinturn:~ $
It is interesting to know that "mh" logged out yesterday and logged in
today, but the gpg-agent.socket seems to stay around when the user logs
out. Is that intended behavior?
Another affected "system user in question" where I noticed the issue is
zgansible, a rather limited account, and journalctl is unwilling to
cooperate here:
[13/4999]mh@spinturn:~ $ sudo -u zgansible -i
$ journalctl --user-unit 'gpg-agent*'
Hint: You are currently not seeing messages from the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.
No journal files were opened due to insufficient permissions.
$
It looks like the unit is started once an ansible run is invoked with
this account, as:
[20/5005]mh@spinturn:~ $ sudo ls -al /run/user/2530/systemd/units
total 0
drwxr-xr-x 2 zgansible nogroup 80 Apr 13 15:16 .
drwxr-xr-x 5 zgansible nogroup 140 Apr 13 15:16 ..
lrwxrwxrwx 1 zgansible nogroup 32 Apr 13 15:16 invocation:gpg-agent.socket -> c8306e63c8d94fb7b83466a89bcb6fbd
lrwxrwxrwx 1 zgansible nogroup 32 Apr 13 15:16 invocation:gpg-agent-ssh.socket -> 911379f7cd814041bba22f208878aef4
[21/5006]mh@spinturn:~ $
and this unit seems to stay around for a while (or indefinetely?) after
the user has logged out after finishing the ansible run.
Greetings
Marc
my ansible user is not in the system user range, but still a system user, as it doesn't originate from a package. I'd really like the socket unit to be stopped on logout. Greetings Marc
Am 13.04.2025 um 15:24 schrieb Marc Haber: That's a bit weird. If it's not in the system range, I personally wouldn't consider it a system user. rather when the last user session ends (a user could be logged in multiple times and the systemd --user instance is refcounted so to speak). Things that can prevent that: - lingering is enabled for that account https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances - Some process(es) refuse to die on logout and keep the session active. Debian disables automatic killing of processes on logout, i.e. it defaults to KillUserProcesses=no https://wiki.archlinux.org/title/Systemd/User#Kill_user_processes_on_logout You can either enabled that option or investigate which program keeps the session active. Michael
Let's call it "a technical user". Such things exist by the hundred in bigger installations. So the files in /run/user/ID/systemd/units should vanish then? That doesn't happen. Not deliberately. Is it the default? It seems to be a socket unit that stays active. Greetings Marc
sorry, this should have been: gpgconf --list-options gpg-agent | grep '^enable-ssh-support:' AFAIK, systemd *should* clean up the user units after the ansible run is complete, if the ansible user terminates cleanly. How is the ansible run triggered? is systemd lingering for this user? you can use "loginctl" to interrogate whether lingering is enabled for a given user or session (e.g., the list-users, user-status, and show-user subcommands).