Remote forwarding gnupg extra-socket?

[Andrew Gallagher]

It used to be that we could tell gpg-agent to create an extra-socket
(with restricted functionality) and then tell ssh to forward that socket
to a remote machine, giving gpg an equivalent agent forwarding
functionality to that of ssh.

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
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
RemoteForward directives.

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.

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

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,
it could optionally support a protocol extension allowing it to tunnel
extra-socket commands back to the originating gpg-agent over the
ssh-agent connection. The gpg on the remote machine could then test for
this protocol extension and if found use the ssh-agent socket instead.
This would remove the need for any custom ssh shenanigans (which only
sort-of work, even now).

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

https://tools.ietf.org/id/draft-miller-ssh-agent-01.html#rfc.section.4.7

What do we think?

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200309/175e7ee9/attachment-0001.sig>