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
