Hi systemd community Last weeks I spent setting up identity caching at my Linux Arch machine. I wanted ssh-agent/gpg-agent functionality configured in a secure, clean and easy to manage way. Unfortunately more I learn about ssh-agent/gpg-agent/gnome keyring/envoy/Keychain more I dislike it.
Both ssh-agent and gpg-agent are daemons that allow to keep private ssh and gpg keys in memory and avoid entering passphrase each time the key is used. I tried to create a systemd service file but it did not looks elegant (more about it later). Many people use wrapper that make ssh-agent/gpg-agent management easier (envoy[1], keychain [2]). The fact that there are such wrappers exist means that agents are either too complex or too hard to use. One of the weirdest decisions made by ssh/gpg developers is using environment variables to pass information about agent processes. Why don't they use some well-known location for the socket file like any other application does? Currently I need to run the *-agent daemon from user account, construct environment variables and propagate it to other processes such as Gnome and terminals started by sshd.service. It would be much nicer if *-agents created /run/user/$uid/gpg-agent.socket that any program can use. Ok, back to systemd service. I tried to create one based on https://github.com/zoqaeski/systemd-user-units/blob/master/user/gpg-agent.service. gpg-agent says itapplications is a drop-in replacement for ssh-agent but I found that gpg-agent does not work if I start it as systemd service - gpg-agent requires terminal where it can run pinentry application (the one where you enter ssh key passphrase). I end up with 2 user services - one for ssh-agent another for gpg-agent with additional scripting in ~/.bashrc that tries to construct GPG_ and SSH_ envvars. But I would love to see just one system daemon for all users without the additional configuration steps. All I expect to start the service is: sudo systemctl enable systemd-keyringd.socket After that 'ssh' 'gpg' should work without any configuration hustle. Here is more fun with these agents: - gdm login manager starts X session as a subshell of ssh-agent. Quoting 'man ssh-agent': "The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.". I believe this is the way to export environment variables to child processes. - gnome3 has its own gnome-keyring-daemon [3] that reimplements ssh-agent/gpg-agent and makes one step towards using best practices plus provides UI client to manage the keyring. So my opinion about the keyring management/identity caching is that it is too weird/complicated. I would like to see someone who can make it more pleasant to use. And yes systemd community I am looking at you. Systemd already manages a bunch of user session information and I wonder if identity caching can be added here as well. What do you think? A good idea would be contact gnome-keyring developers and ask them to their their experience. But unlike gnome3 version of keyring daemon the systemd should be UI independent and work with gnome/kde/headless machines. [1] https://github.com/vodik/envoy [2] http://www.funtoo.org/Keychain [3] https://git.gnome.org/browse/gnome-keyring/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
