Bug#961311: ssh-agent.service: cannot work without x11-common installed
Hi there,
Maybe I'm being hopelessly naive, but is there any value in tying
ssh-agent to X11/Wayland or trying to make it behave like a session
service (as opposed to a user service), or having this "agent-launch"
init script at all?
Personally, I've been using a systemd "global" user unit to manage my
ssh-agent for a couple of years, with a consistent socket location and
no checks for Xsession.options or session type or anything, and I love
it.
$ cat /etc/systemd/user/ssh-agent.service
[Unit]
Description=SSH key agent
[Service]
Type=exec
# %t resolves to XDG_RUNTIME_DIR; see SPECIFIERS section in
systemd.unit(5)
ExecStart=/usr/bin/ssh-agent -D -a "%t/ssh-agent.socket"
[Install]
WantedBy=default.target
To my mind, one of the big advantages of simply letting systemd manage
it is the fact that it's *not* doing any GUI-specific or per-session
cleverness. If I'm logged into XFCE4 and have keys loaded into
ssh-agent, then swap out to VT1 and log in there: systemd no-ops
ssh-agent.service because it's already running. Then I restart lightdm,
which kills the session where I started the agent initially: because I
still have a non-zero number of logged-in sessions, systemd keeps my
ssh-agent.service up, and I can access it right there in VT1. Swap back
to the lightdm greeter and log in to whatever DE, and my agent is still
running, the keys are still loaded, the socket is still where it's
expected to be, and everything Just Works™. On a server where I don't
have X or Wayland or any graphical anything installed, my ssh-agent
still starts when I log in, and everything works exactly the same way.
Why in the world would I want my ssh-agent to not work just because I
don't have X installed?
Any user who doesn't want it can use "systemctl --user disable (or mask)
ssh-agent", or root can do the same for all users with "systemctl
--global", so the blunt implement of .Xsession.options "use-ssh-agent"
option is obsolete.
By far the hardest part of this has been tracking down all the legacy
session scripts and DE hacks and things that kept launching ssh-agent
even though it was already running, (or gnome-keyring trying to
emulate ssh-agent, poorly) and clobbering my SSH_AUTH_SOCK env-var.
As I say, maybe I'm being naive, but I'm tempted to suggest dropping
the ConditionPathExists, doing away with /usr/lib/openssh/agent-launch
completely, dropping the check for "use-ssh-agent" (preferably with a
comment in that file pointing out that the option is deprecated because
enabling/disabling the service with systemd is more granular, more
flexible, more consistent, and more reliable), and starting the agent
directly with ExecStart.
Since the socket location doesn't change, and the user being logged in
*at all* will trigger systemd to start their ssh-agent.service, is
there any need to set and unset SSH_AUTH_SOCK dynamically instead of
just setting it once at login like most env-vars? I guess setting it
dynamically would have the advantage that if *yet another* legacy
workaround launches its own ssh-agent and clobbers the env-var,
restarting ssh-agent.service would clobber it right back.
If we *do* want to dynamically set and unset SSH_AUTH_SOCK, why not do
it directly in the .service file with ExecStartPre and ExecStartPost
directives? I'd prefix the ExecStartPre one with a "-" though, so if
dbus isn't available the service can still start.
Does that make any sense?
Cheers!
-Chris
Reply to: