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.)
OpenSSH 6.8 released
11–20 of 44 posts
Re: OpenSSH 6.8 released
#12> * 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
#13Re: OpenSSH 6.8 released
#14The 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.…
Re: OpenSSH 6.8 released
#15I 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.
Re: OpenSSH 6.8 released
#16Earlier 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. :)
Re: OpenSSH 6.8 released
#17 http://w8rbt.org/patches/sshlog.patchRe: OpenSSH 6.8 released
#18Re: OpenSSH 6.8 released
#19Earlier 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?
Re: OpenSSH 6.8 released
#20Earlier 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.
So yeah, I suppose if your platform supports PAM this is feasible.