On Fri, Jun 06, 2014 at 10:41:24AM -0700, Patrick Burroughs (Celti) wrote:

On Fri, Jun 6, 2014 at 10:14 AM, Magnus Therning wrote:

...

I have a feeling this ought to be solvable using systemd but I can't really see how. Writing a service for gpg-agent is not that difficult, and it creates the required environment file without problems. But, how do I hook it in to the user login in the right way? Who should be wanting my gpg-agent.service, and then load the generated file using EnvironmentFile=?

Rather than starting it purely with systemd, have you looked into using Envoy [1] and using its PAM module to ensure it gets propagated to the entire login session?

Thanks. I did the following - start the systemd service envoy@ssh-agent.socket - add pam_envoy.so to /etc/pam.d/system-login That got it working for ssh, but not for gpg. Is there something else I should do to also get gpg-agent support? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

(Tue, Jun 10, 2014 at 03:06:12PM +0200) Bjørnar Hansen :

On Sun, Jun 8, 2014 at 10:21 PM, Magnus Therning wrote:

...

I did the following

- start the systemd service envoy@ssh-agent.socket - add pam_envoy.so to /etc/pam.d/system-login

That got it working for ssh, but not for gpg. Is there something else I should do to also get gpg-agent support?

Did you also start the systemd service envoy@gpg-agent.socket?

No, you cannot start both. However, if you start the gpg-agent version then you automatically have the ssh-agent with it. It's more or less the same as the legacy gpg-agent. As far as I am concerned I don't like that and prefer to separate ssh agent from gpg agent (KISS, bla bla), so to answer to the OP more precisely and without using envoy: For gpg-agent, you can add something like that in your $HOME/.config/systemd/user/gpg-agent.service ----------- [Unit] Description=gpg-agent ConditionFileIsExecutable=/usr/bin/gpg-agent [Service] ExecStart=/usr/bin/gpg-agent --daemon --write-env-file %h/.gpg-agent-info Type=forking Restart=always ---------- and make sure that it is started by your systemd session. For that refer to the archlinux wiki: https://wiki.archlinux.org/index.php/Systemd/User Then, any application that needs it should simply source the file source $HOME/.gpg-agent-info (for instance in your bashrc) This is not a good solution for two reasons: - You can have race condition between the gpg-agent start and the bash start, which will then source a wrong file. You have no way to prevent that as your session starts in parallel with the user-services - Same problem if by chance the gpg agent fails and restart, putting his socket somewhere else (which it will). There has been a ticket about that in the gpg mailing-list, which they chose not to address http://lists.gnupg.org/pipermail/gnupg-devel/2012-October/026983.html So there is not really a solution so far. For ssh-agent it's a bit simpler: $HOME/.config/systemd/user/ssh-agent.service ---------------- [Unit] Description=ssh-agent ConditionFileIsExecutable=/usr/bin/ssh-agent [Service] ExecStart=/usr/bin/ssh-agent -d -a %t/ssh_auth_sock Restart=always ---------------- And in your .bashrc/.xsession you simply need to add a export SSH_AUTH_SOCK=/var/run/user/1000/ssh_auth_sock The above problem won't show up as we can force the agent to put it's socket in a predictable place. Cheers, -- Ismael