SSH generic socket forwarding for gpg-agent

[Daniel Kahn Gillmor]

On Thu 2014-12-04 03:23:52 -0500, Werner Koch wrote:
> On Tue, 11 Nov 2014 18:35, matt at monaco.cx said:
>> Does anyone have gpg-agent forwarding working with SSH's recent generic socket
>> forwarding? Does it still require socat on one end, because I've only been able
>> to specify a socket path on the left-hand side of the forwarding
>> specification
>
> Yes, it works for me.  However, I tested it with the current development
> version of 2.1 which adds an extra features:
>
>    --extra-socket NAME
>           Also listen on native gpg-agent connections on the given
>           socket.  The intended use for this extra socket is to
>           setup a Unix domain socket forwarding from a remote
>           machine to this socket on the local machine.  A gpg
>           running on the remote machine may then connect to the
>           local gpg-agent and use its private keys.  This allows to
>           decrypt or sign data on a remote machine without exposing
>           the private keys to the remote machine.
>
> The documentation on how to use Unix domain sockets with ssh is a bit
> sparse.  You probably want to use "-o StreamLocalBindUnlink=yes" when
> connecting to the remote host and you have to enable the forwarding
> features (look for Stream* options).

Encouraging this kind of use seems risky.  I certainly wouldn't want to
do it without being able to have gpg-agent prompt me on my local machine
for each use of the key.  Its current silent operation once the
passphrase is cached seems ripe for abuse by anyone in control of the
remote account.

Could gpg-agent have a setting (per-key? per-agent?) that would have it
use pinentry for prompting?

The traditional argument against this sort of feature is that someone
with control over your local socket would most likely have control over
your graphical environment, and therefore could dismiss or hide any
prompt that comes up (so the prompting is a false sense of security).
I'm not sure i buy this argument in general (i see it as
defense-in-depth rather than a false sense of security, since it's one
more hurdle the attacker needs to clear), but it certainly doesn't hold
when there is a clear security boundary like gpg-agent forwarded over a
network socket.

        --dkg