[systemd-devel] Keyring service as a natural use-case for systemd?

[Anatol Pomozov]

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/