OpenSSH 6.8 released | Hacker News Reader

OpenSSH 6.8 released

lists.mindrot.org

95 pointsmukyu42 comments

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.

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.

But you don't want users to think they're normal and should be ignored. They're an exceptional case and should be understood.

I think you should read the message you are responding to again, as you just agreed with what I said.

I submitted a very detailed bug report[0] a while ago, which can lead to a DoS (albeit in a very specific setting). I don't expect anyone to rush to fix it, but I'm surprised that there isn't even a comment about it. Is there another place it needs to be reported in?

[0] https://bugzilla.mindrot.org/show_bug.cgi?id=2265

Try pointing it out on the mailing list ( openssh-unix-dev@mindrot.org ).

Having been on both user and the developer sides, with F/OSS projects, more developers are likely to read every post on the mailing list than every report in the bug tracker.

The --without-openssl option is particularly attractive on Linux systems if you distrust openssl's code.

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.

Sure. I simply use it for crypto primitives (e.g. aes-256-gcm) in environments where I cannot install libsodium from PECL (e.g. crypto_easybox() and crypto_easybox_open()).

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?

Have you switched everything to Ed25519 keys?

It is also useful for embedded devices with small flash/ROM.

Finally UseDNS is set to 'no' by default. This is the thing I was ALWAYS changing :)

I always felt guilty about it, as if I was perhaps missing something obvious. :)

Glad to see it gone in the defaults.

> [...] SSH protocol version 1.3, 1.5 [...]

Do we still need these? Aren't they extremely ancient? Is there any old client that only support these protocol versions and has no security issues, or is out-of-support?

I've got a few older Dell switches that still work wonderfully, but only connect via ssh1, not ssh2. They're still useful, and setting up a management vlan isn't that hard, so replacing them is a proposition that's much more expensive than it's worth.

That sort of avoids the question: Do those machines still get an up-to-date OpenSSH that's considered trustworthy today? Is there some impediment to upgrade OpenSSH on them?

"Twitter poll for Unix users: do you still use SSH v.1? If so, how often? Pls. only reply if 'yes' to first question, otherwise RT welcome :)"

https://twitter.com/damienmiller/status/570409396913614849

Damien Miller is part of the OpenSSH team, so I guess they are considering cleaning that part of the code.

https://bugzilla.mindrot.org/show_bug.cgi?id=1424 :(

Oh well, refactoring and crypto work is certainly more important. Congrats on the release.

I have to configure ssh servers so that putty is able to connect, so I can't follow best practices. Why don't the people working in this area help the putty project with support for the latest stuff?

Why don't the people who use and depend on putty help the project with support for the things they need?

There aren't a lot of people qualified to work on security software.

What best practices would prevent Putty from connecting? Afaik, I'm using most best practices on my own server, and I can connect with Putty just fine.

AFAIK, Ed25519 keys and Curve25519 key exchange, AES GCM symmetric encryption.

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

Wouldn't that be more in the scope of PAM than an SSHd?

Edit: https://github.com/Yubico/pam-u2f

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.

Track https://bugzilla.mindrot.org/show_bug.cgi?id=2319

I worked on this for a while, but lost motivation because of the slow development speed. If you’re more motivated, you’re very welcome to pick up where I left and bring this to thousends of users :).

OpenSSH is certainly the standard amongst SSH servers, however, I'm curious if there are serious alternatives that offer something missing in OpenSSH? I know there's a patch floating around that allowed some buffer to be configurable and boosted `scp` performance, for example, but I'm curious if there are other servers that offer anything else interesting.

You might find it worth while to investigate mosh[0] as an alternative to OpenSSH.

[0] - https://mosh.mit.edu/

mosh uses openssh (or some other ssh) under the covers to perform authn + authz and start the remote mosh server (and possibly to communicate the udp port that the remote mosh server is listening on to the client mosh?)

Dropbear is a lightweight replacement for OpenSSH. It runs on things like routers (openwrt) and certain android ROMs.

Used it through an sshserver app for Android, had no troubles doing a full scp -R <phone> <backup> with it.

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..

The sshlog (password logging) patch still seems to work on 6.8

    http://w8rbt.org/patches/sshlog.patch

wget is blocked on that URL, any specific reason?

wget --user-agent="Not wget" http://w8rbt.org/patches/sshlog.patch

works.

Reply on news.ycombinator.com