OpenSSH developer Damien Miller wrote from Down Under about a new feature he implemented and committed for the next upcoming 6.8 release of OpenSSH — hostkeys@openssh.com — an OpenSSH extension to the SSH protocol for sshd to automatically send all of its public keys to the client, and for the client to automatically replace all keys of such server within ~/.ssh/known_hosts with the fresh copies as supplied (provided the server is trusted in the first place, of course).
The protocol extension is simple enough, and is aimed to make it easier to switch over from DSA to the OpenSSL-free Ed25519 public keys. It is also designed in such a way as to support the concept of spare host keys being stored offline, which could then seamlessly replace main active keys should they ever become compromised.
Related Stories
The Latacora firm has a blog post asserting that OpenSSH-portable has poor defaults for encrypting private RSA keys because of its reliance on OpenSSL. The blog goes into why this is a problem and how you can test it for yourself.
There is nothing wrong with the generated RSA keys themselves, however, just the encryption of the private RSA keys -- if made using current defaults. There are two ways of encrypting RSA keys, an old and apparently insecure way, and a new key format available but not default. Newer key types like Ed25519 use only the new key format and are not bothered by this problem.
Earlier on SN:
WikiLeaks Unveils CIA Implants That Steal SSH Credentials From Windows, Linux PCs (2017)
Upgrade Your SSH Keys (2016)
OpenSSH 6.8 Will Feature Key Discovery and Rotation for Easier Switching to DJB's Ed25519 (2015)
What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality - with the help of some recently adopted crypto from DJ Bernstein. OpenSSH now finally has a compile-time option to no longer depend on OpenSSL, the option `make OPENSSL=no` has now been introduced for a reduced-configuration OpenSSH to be built without OpenSSL.
The result would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys.
[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
(Score: 5, Interesting) by Jeremiah Cornelius on Sunday February 01 2015, @02:44PM
Beloved for years to come by the NSA and GCHQ.
You're betting on the pantomime horse...
(Score: 0, Offtopic) by Anonymous Coward on Sunday February 01 2015, @05:17PM
Looks like "+1 disagree" is going to end up really meaning "+1 banal and trite."
(Score: 1) by cnst on Sunday February 01 2015, @04:46PM
Anyone knows why the internal link, from "OpenSSL-free", not working? Looks like it somehow ended up with having "tid" string appended at the end, which was not part of my submission. Any moderators care to fix?
(Score: 2) by The Mighty Buzzard on Sunday February 01 2015, @06:51PM
Fixed, thanks for the heads up.
My rights don't end where your fear begins.
(Score: 4, Insightful) by mtrycz on Sunday February 01 2015, @06:42PM
How am I to get a grip of all this complexity, let alone a normal dayotday user?
In capitalist America, ads view YOU!
(Score: 5, Insightful) by Adamsjas on Sunday February 01 2015, @10:10PM
Quote TFS:
"for the client to automatically replace all keys of such server within ~/.ssh/known_hosts with the fresh copies as supplied "
"It is also designed in such a way as to support the concept of spare host keys being stored offline, which could then seamlessly replace main active keys should they ever become compromised."
You better hope this gets very carefully vetted.
On the surface this seems like a backward step, one of those bloat-ware features that gets added with good intentions that bites you down the road a ways.
Its good to change you host keys once in a while. Then carefully distribute your public keys to just those people who need access. And invite/force those people to upload their public keys again. Sheds a lot of forgotten access handed out over the years.
But doing this automatically and handing ALL your new public keys to anyone who had them previously really sheds nothing.