Agent forwarding failure when the socketdir was autodeleted

Daniel Kahn Gillmor dkg at
Tue Oct 4 21:34:25 CEST 2016

Hi Andre--

On Tue 2016-10-04 14:49:00 -0400, Andre Heinecke wrote:

> On Tuesday 04 October 2016 11:26:59 Daniel Kahn Gillmor wrote:
>> > But if I am not logged in or there is no gnupg process running. systemd
>> > autodeletes /var/run/user/<uid>/gnupg this causes the remote forward of
>> > the
>> > Socket to fail because the directory for the socket does not exist and SSH
>> > won't create it. :-/
>> If you're not logged in, then how does the remote forward work?  aren't
>> you actually still logged in (via ssh) as long as your remote forward is
>> running?
> Sorry for not formulating this better. You are of course right If I'm not 
> logged in the remote forward is not working.
> That is not what I meant to say. The problem is, that when I disconnect the 
> /run/.../gnupg dir is deleted and the next time I want to connect and ssh 
> tries to set up the forwarding this will fail because the /run/.../gnupg 
> directory in which the forwarded socket should be created does not exist.

so /run/user/<uid> exists upon ssh connection, but
/run/user/<uid>/gnupg/  does not, and therefore sshd on the remote side
of the pipe can't auto-create the remote socket -- is that the concern?

> My current workaround is to connect first and start dirmngr on the remote 
> machine (to get the socketdir created and used). And then connect with ssh 
> socket forwarding. This is a bit clunky to use.

agreed, that sounds clunky and annoying.

I wonder whether ssh's remote socket forwarding ought to try to
automatically create the parent directories if they don't already exist.

This doesn't solve your problem in the near term if you can't update the
remote host, but it seems like the right place to fix this problem.

Maybe that's worth asking on openssh-unix-dev at ?

> I've tried placing files in that folder, or to set up permissions to 000 for 
> the gnupg folder (so that gnupg itself does not use it) but to no avail. It's 
> still removed when disconnecting and the next connect will fail.

right, session termination (or machine reboot, etc) should clean up
/run/user/<uid> entirely -- that's part of the explicit goal of

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161004/b821379d/attachment.sig>

More information about the Gnupg-users mailing list