Remote forwarding gnupg extra-socket?

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Mar 27 05:09:58 CET 2020


Hi Andrew--

On Mon 2020-03-09 13:02:55 +0000, Andrew Gallagher wrote:
> 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.

the extra-socket is created automatically these days, and doesn't need
to be enabled explicitly.

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

There has been some discussion about this over on the SSH bugtracker:

https://bugzilla.mindrot.org/show_bug.cgi?id=3018
https://bugzilla.mindrot.org/show_bug.cgi?id=2740
https://bugzilla.mindrot.org/show_bug.cgi?id=3014
https://bugzilla.mindrot.org/show_bug.cgi?id=3140

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

I'm not convinced that this is a good idea; more configurability means
more ways that people can break their setups, and debugging is even
harder.

> 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

this is a very interesting suggestion, but i'm not sure exactly how it
would work.  can you describe it in more detail?  At the beginning of
this message, it looks like you were talking about forwarding the
extra-socket, and now it looks like you're talking about forwarding the
ssh-agent emulation.  Are you talking about the same concern here?
they're (at least subtly) different.

Also, how is the remote gpg-agent supposed to know that there is some
other backend it should talk to (for either ssh-agent or any of the
gpg-agent sockets)?

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20200327/d3c04b3a/attachment.sig>


More information about the Gnupg-devel mailing list