Live data from Hacker News

OpenSSH 6.8 released

lists.mindrot.org

11–20 of 44 posts

Re: OpenSSH 6.8 released

#11
post #6

Earlier quoted context omitted.

What functionality do you lose if you build it with that option?

From the article: Disables and removes dependency on OpenSSL. Many features, including SSH protocol 1 are not supported and the set of crypto options is greatly restricted. This will only work on systems with native arc4random or /dev/urandom. I haven't dug into the source code, but I'd wager that the crypto options that remain are Ed25519, ChaCha20-Poly1305, etc. (Don't quote me on this, however.)

So if I (like most people with modern systems) only use SSH2 + AES, I should be OK?

Re: OpenSSH 6.8 released

#12
The host key rotation support sounds very nice, and something I've wanted for a long time:

> * ssh(1), sshd(8): Experimental host key rotation support. Add a protocol extension for a server to inform a client of all its available host keys after authentication has completed. The client may record the keys in known_hosts, allowing it to upgrade to better host key algorithms and a server to gracefully rotate its keys.

> The client side of this is controlled by a UpdateHostkeys config option (default off).

I wish it were on by default, but I guess they want to test it further before enabling it by default. It will remove the temptation to keep using old, weak or suspect keys just because of the hassle of having all the users update their keys or because the admins are afraid of training their users that the scary "HOST KEY HAS CHANGED!!!" warnings are normal and should be ignored.

Re: OpenSSH 6.8 released

#14

The host key rotation support sounds very nice, and something I've wanted for a long time: > * ssh(1), sshd(8): Experimental host key rotation support. Add a protocol extension for a server to inform a client of all its available host keys after authentication has completed. The client may record the keys in known_hosts, allowing it to upgrade to better host key algorithms and a server to gracefully rotate its keys.…

I agree, it's an exciting feature with a lot of promise. It does have some potential for abuse, and I think defaulting to off is the proper choice. Even when it's no longer experimental, this is something I imagine you'd want to enable on a per server basis.

Re: OpenSSH 6.8 released

#15
post #9
post #2

I was hoping for U2F but I guess it's not ready yet. :)

Chrome has access to USB and its own code to handle U2F devices. This would require your SSH client to have the same capabilities. This might work well on Linux/BSD machines, but likely not on OSX due to stagnant unix utility updates and Windows because... well, not a real Unix. Would probably require a heavy wrapper around Putty. Not sure if cygwin and friends would ever work either.

OSX supports PAM auth, U2F is just another kind of PAM. That's how I use my Yubikey.

Re: OpenSSH 6.8 released

#16
post #5

Earlier quoted context omitted.

It is, but please note that OpenSSH uses very little of OpenSSL's code. None of the serious bugs lately had any impact on OpenSSH.

That's probably very reassuring. I personally don't share this belief that openssl is bad (in fact, for PHP developers, openssl is preferable to libmcrypt which has been abandoned since 2007), I just know it's a common sentiment of infosec people. :)

Just because OpenSSL is very hard to replace doesn't mean it's not very bad.

Re: OpenSSH 6.8 released

#18
Fingerprint hash tracking is on the plan to add to Userify soon as well, along with host key wipe and regen. Can't wait to get some of these other awesome features mixed in. Of course, we'll have to wait for distributions to catch up.. queue five year wait..

Re: OpenSSH 6.8 released

#19
post #11

Earlier quoted context omitted.

From the article: Disables and removes dependency on OpenSSL. Many features, including SSH protocol 1 are not supported and the set of crypto options is greatly restricted. This will only work on systems with native arc4random or /dev/urandom. I haven't dug into the source code, but I'd wager that the crypto options that remain are Ed25519, ChaCha20-Poly1305, etc. (Don't quote me on this, however.)

So if I (like most people with modern systems) only use SSH2 + AES, I should be OK?

Have you switched everything to Ed25519 keys?

Re: OpenSSH 6.8 released

#20
post #15
post #9

Earlier quoted context omitted.

Chrome has access to USB and its own code to handle U2F devices. This would require your SSH client to have the same capabilities. This might work well on Linux/BSD machines, but likely not on OSX due to stagnant unix utility updates and Windows because... well, not a real Unix. Would probably require a heavy wrapper around Putty. Not sure if cygwin and friends would ever work either.

OSX supports PAM auth, U2F is just another kind of PAM. That's how I use my Yubikey.

I was thinking that server side it was a PAM module, but client side it was not... for some bizarre reason.

So yeah, I suppose if your platform supports PAM this is feasible.

Post reply on HN