Re: Starting gpg-agent from systemd?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



(Tue, Jun 10, 2014 at 03:06:12PM +0200) Bjørnar Hansen :
> On Sun, Jun 8, 2014 at 10:21 PM, Magnus Therning <magnus@xxxxxxxxxxxx> 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

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux