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> _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
