Jul. 26, 2022 17:00:46 Greg Wooledge <g...@wooledge.org>:
> On Tue, Jul 26, 2022 at 03:40:48PM -0300, Chris Mitchell wrote: >> Here's my service file: >> >> $ cat /etc/systemd/user/ssh-agent.service > > According to systemd.unit(5) this directory is for "User units created > by the administrator". Yup, that's me! In practice, it means units placed there are user units that are available to all users on the system, so they can start/stop/enable/disable/… their own instances of those units via "systemctl --user" commands (or root can do the same for all users at once with "systemctl --global). A unit in this directory will supersede a same-named unit in /usr/lib/systemd/user, and may in turn be superseded on a user-by-user basis via their respective ~/.config/systemd/user directories. > PID 1 is the system instance of systemd. Not a user instance. > The ssh-agent with PID 3011 is being started by the system instance, > so it is a system unit. It's not your locally defined user unit. Oh, yes. I should have realized that. Weird that the system instance would be configured to start an ssh-agent at all, but I'll definitely look there next. > Things you should look at next, I suppose: > > systemctl status ssh-agent > systemctl --user status ssh-agent The --user one shows that my custom "global" user unit at /etc/systemd/user is up and running as expected, which I can verify by manually changing SSH_AUTH_SOCK to point to the socket specified there and accessing the agent. If the *system* systemd instance is actually launching an ssh-agent and injecting corresponding env-vars into my regular user environment, that is deeply strange, and I'm reasonably sure I haven't done anything that could cause that outcome. # systemctl status ssh-agent.service Unit ssh-agent.service could not be found. # systemctl list-units --all *ssh* UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. > Starting an ssh-agent via systemd is completely outside of my > experience, though, and I don't really understand why you'd attempt > it. It's not clear to me *at all* how you would communicate the > environment variables from the ssh-agent invocation over to the > user's login session. My setup is to have each user's "user" systemd instance manage their ssh-agent (which is also how the Bookworm package handles it, though with some differences in the implementation details). Being a long-running daemon type process that provides a service to other processes, ssh-agent struck me as an ideal candidate for being handled by the service manager. The only environment variable that remains relevant now that systemd handles the process control stuff is SSH_AUTH_SOCK, and because I specify a consistent socket location, I can set that statically for all login sessions, the same way you would go about adding a custom location to PATH or whatever. Advantages include: * hands-on learning experience with systemd, which is clearly here to stay, * make ssh-agent start, and behave consistently, regardless of what DE I use, or no DE, or no X or Wayland or graphical anything, * any user who has a non-zero number of active login sessions gets exactly one ssh-agent process, regardless of what "type" of session(s) For example: if I log in to XFCE4, load a few ssh keys into my ssh-agent, and something causes X to hang, I swap to VT1 and log in there. Systemd no-ops my ssh-agent.service because it's already running, and access to ssh-agent works right there in VT1, including the already-loaded keys. Now I restart lightdm, which kills the session that started my ssh-agent.service, but because I still have a non-zero number of active login sessions (VT1), systemd keeps that service running. Then I can swap back to the lightdm greeter and log in to XFCE4, or KDE, or Enlightenment, or whatever, and my ssh-agent is already up and ready with the keys I loaded earlier. Just for fun, if I want to make ssh-agent socket-activated for every user on the system instead of auto-started at login, I can drop a ~5 line ssh-agent.socket file in /etc/systemd/user/ alongside the ssh-agent.service file, systemctl --global disable the .service unit and enable the .socket unit instead, and that's it. I've been using this "global" systemd user unit to manage ssh-agent for a couple of years now, and it's just about perfect… except when some legacy workaround comes along and clobbers things. Cheers! -Chris