Remote forwarding gnupg extra-socket?

Werner Koch wk at
Fri Mar 27 14:20:35 CET 2020

On Mon,  9 Mar 2020 13:02, Andrew Gallagher said:

> In fact, you can still configure all of the above, but doing so is now
> next to useless. Since v2.1 there is no way to tell the remote gpg
> instance to use a non-default socket, and there is no reliable way to

Actually --extra-socket was introduced with 2.1.1 and the /var/run
standard location was introduced with 2.1.13.  So I don't understand why
you think anything has changed for --extra-socket except that it is now
always generated unless you configure "extra-socket /dev/null"

> tell ssh to mount the forwarded socket on the default location -- the
> default is now under XDG_RUNTIME_DIR which is unpredictable in
> principle, and ssh does not allow the use of remote envars in

XDG_RUNTIME_DIR is not used:

  /* It has been suggested to first check XDG_RUNTIME_DIR envvar.
   * However, the specs state that the lifetime of the directory MUST
   * be bound to the user being logged in.  Now GnuPG may also be run
   * as a background process with no (desktop) user logged in.  Thus
   * we better don't do that.  */

We use /run/user/<uid> instead.

[Site note: It seems that this directory is sometimes used for
 XDG_RUNTIME_DIR or at least handled in that way.  Which is a pretty
 annoying misfeature.  I often fall into this trap:

  foo-box$ ssh -X bar-box
  bar-box$ ssh foo-box
  foo-box$ exit

 After the "exit" elogind removes /run/user/<uid> and futher work (in
 paricular new ssh connections) stop working because SSH_AUTH_SOCK
 points to a now non-existing socket.
 Mitigation is "loginctl enable-linger".

> Not only that, but if you are already logged in to the remote machine by
> other means you MUST NOT use the default socket location lest you break
> the existing session.

You mean you are running a gpg-agent on the remote box as well?  Right
in this case you should use a different home directory for the remote use
of gpg-agent.  gpgconf has options to help you with that.  And of course
you should use


     Do not start the gpg-agent or the dirmngr if it has not yet been
     started and its service is required.  This option is mostly useful
     on machines where the connection to gpg-agent has been redirected
     to another machines.  If dirmngr is required on the remote machine,
     it may be started manually using gpgconf --launch dirmngr.

with your remote gpg.

> Can we please PLEASE have GPG_AGENT_SOCK back in the short term?

No, the removal solved so many problems that it will definitely not be
added again.  The rule is: one gnupg homedir - one socket directory.

> In the long term, it might be more productive to overload ssh-agent. IFF
> the forwarded ssh-agent is really a gnupg-agent with enable-ssh-support,

That is a misunderstanding: gpg-agent does not emulate ssh-agent but
implements the ssh-agent-protocol; in that protocol gpg-agent is the
server and ssh is the client.

> The ssh-agent protocol allows for vendor-specific protocol extensions,
> which would appear to be perfectly suited for this:

Yes, it would be nice if the client site (ssh)  would send certain
environment variables via the ssh-agent-protocol, so that gpg-agent
knows hows where to pop up the pinentry (that is what the gpg does).
It would also be very nice if ssh could be extended to call a configured
tool if it does not find an agent and then try again.  This way we would
get auto start also via ssh.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 2734 bytes
Desc: not available
URL: <>

More information about the Gnupg-devel mailing list