OpenSSH 6.7 released

Posted Oct 8, 2014 0:56 UTC (Wed) by josh (subscriber, #17465)
Parent article: OpenSSH 6.7 released

The ability to forward UNIX domain sockets seems wildly useful. I'm looking forward to a variety of new applications for this, as a generalized version of "ssh -X" and "ssh -A".

OpenSSH 6.7 released

Posted Oct 8, 2014 6:57 UTC (Wed) by lkundrak (subscriber, #43452) [Link]

I guess you'll be able to forward dbus sockets and forward your dconf to remote or maybe send-notifications with notify-send once a remote job is done. Nice.

OpenSSH 6.7 released

Posted Oct 8, 2014 8:10 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (12 responses)

Forwarding the gpg agent makes it much simpler and much more useful to use smartcards for signing code, for example. And by needing both a smartcard and a smartcard PIN, you effectively get two factor authentication for free.

OpenSSH 6.7 released

Posted Oct 9, 2014 8:08 UTC (Thu) by grawity (subscriber, #80596) [Link] (2 responses)

Unfortunately, GnuPG 2.1 now hardcodes the socket path, which makes this a little bit less convenient – can't have different sockets per session anymore (as a result, if you close the 'forwarding' session, all other sessions break), and can't even use forwarded and locally-running gpg-agent from different sessions.

OpenSSH 6.7 released

Posted Oct 9, 2014 14:59 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

You can always use a different GNUPGHOME.

Given that not all file systems support sockets, the plan is to allow a pseudo socket file to redirect to the real socket. If you post your use-case to gnupg-devel or -users, we can see now we can help you out.

OpenSSH 6.7 released

Posted Oct 10, 2014 9:57 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

"ssh -N" for the win!

OpenSSH 6.7 released

Posted Oct 9, 2014 9:06 UTC (Thu) by cortana (subscriber, #24596) [Link] (8 responses)

It is not safe to forward the connection to your GPG agent to any host you don't trust. Unless I'm mistaken and/or GPG has changed, the GPG agent works by handing the private key over to the client, and the cryptographic operations are performed on the client side. So anyone who can talk to the socket can grab your plaintext key!

OpenSSH 6.7 released

Posted Oct 9, 2014 15:04 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link] (6 responses)

No, that is not true: Before 2.1 gpg-agent acted only as a passphrase cache for gpg. With 2.1 gpg changes to behave as gpgsm has always done: Only the gpg-agent has control over your private keys and gpg receives just the session key from gpg-agent. Thus running gpg on the server and gpg-agent on your client/desktop protects your private key against a compromised server. But not the plaintext of course.

OpenSSH 6.7 released

Posted Oct 10, 2014 7:21 UTC (Fri) by kleptog (subscriber, #1183) [Link] (2 responses)

So all you need now is a dialog that says "someone is trying to sign something with key X" (Accept/Deny) and we can have nice things.

Does such a dialog exist for ssh-agent?

OpenSSH 6.7 released

Posted Oct 10, 2014 8:37 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

You mean ssh-add's -c option? If you use "ssh-add -c" for putting an ssh key into gpg-agent, that flag is set. If you want to change it later, you can add it to ~/.gnupg/sshcontrol.

OpenSSH 6.7 released

Posted Oct 11, 2014 10:51 UTC (Sat) by kleptog (subscriber, #1183) [Link]

Wow! Why did I not know about this option. Thanks a lot!

OpenSSH 6.7 released

Posted Oct 10, 2014 10:56 UTC (Fri) by cortana (subscriber, #24596) [Link] (2 responses)

Hmm, won't the GET_PASSPHRASE command still return me the user's passphrase?

OpenSSH 6.7 released

Posted Oct 10, 2014 13:37 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

GnuPG 2.1 does not use this command anymore. But you raise a good idea. There should be an option to disable this command to not help malware to trick the user into entering the passphrase.

OpenSSH 6.7 released

Posted Oct 13, 2014 8:53 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

I recommend the following series of steps to get from where you are to where you would like to be with the maximum of security and minimum of inconvenience to the end users

1. Add option to disable, but default enabled for existing installs
2. Add warning when user has not made explicit choice to enable / disable
3. Change default to disabled
4. Remove warning

OpenSSH 6.7 released

Posted Oct 10, 2014 9:56 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

I do trust the host. I just want to keep the private keys physically where I am.