gpg-agent forwarding (was Re: Help needed to setup Passphrase with GNUPG 2.0.26 on Solaris 10)

[Peter Lebbing]

On 05/11/14 22:09, Werner Koch wrote:
> It might be worth to check whether there is an interest in running gpg on
> the server via Putty and have Putty forward the communication of gpg to
> a gpg-agent+pinentry running on Windows.

I think this certainly has its upsides, running the agent on the console
of the user instead of the system they ssh into. If the agent is simply
used as a method of password entry, the password is passed over the SSH
connection just as it is when entering the password in a curses pinentry
running on the system where gpg runs. When it's used with a smartcard,
this would mean the user can use it on his console, possibly even
entering the PIN on the pinpad of the reader. When it's used as it is in
GnuPG 2.1, the whole setup changes (as it does for the smartcard, btw),
because now the private key needs to be on the console instead of the
server running gpg.

But there are security issues.

How would this be implemented? I can think of two options: a TCP port,
forwarded by PuTTY, and an SSH subsystem.

Assume it's a TCP port listening on the console.

A TCP port is accessible by anyone. Even when you restrict it to
localhost, this exposes it to any other user on a multi-user system.
With the traditional setup, I think usually only root/admin/... and the
intended user can access an agent. On Linux, I think you can get the
owner of the socket, so you could simply verify the UID. But this is
non-portable. When you use a cookie to control access, you need a way to
get that cookie to the server where gpg is running. This could be solved
by instructing the user to copy the text of the cookie, presented by a
pinentry dialog, to the server. A separate helper "gpg-setup-cookie"
perhaps, invoked sometime after the user logs in (or when they do) and
before they use gpg.
Additionally, I think a TCP port might tempt people to construct truly
unsafe constructions, where the port is not forwarded by an SSH client
or otherwise suitably protected.

But perhaps an SSH subsystem is a nice alternative? This would change
the direction of initiation: the agent would need to connect to the
server via SSH. But it does include full user authentication and
provides a secure channel.

An SSH subsystem is, broadly, simply an SSH connection, but instead of
starting a shell and sending standard input and standard output over the
SSH channel, it starts a specified command with its stdin and stdout
sent over the SSH channel. This is also possible without using a
subsystem, but subsystems are specifically tailored to SSH. Though maybe
their primary feature is the possibility to enable access to subsystems
without enabling shell access, which is not needed in this case.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>