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.
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?
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.
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. :)
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()).
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.)
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?
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?
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.
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.
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.
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?)
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..
> * 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.