Hacker News Reader

> You have much more context about your environment- you know what you need to connect to, what needs to connect to you, and what ciphers, key length, and other configuration that you must support. Therefore if you take all that into account you might be able to optimize for security by disabling compatibility options you don’t need.

As long as that's what you actually do. If instead you want a checklist to blindly execute to "harden" your system, then the grandparent commenter is correct: either your can accept that your distribution's defaults are actually good enough, or you're removing functionality such that you'll find a hurdle you've left for yourself sooner or later.

If your OS distributor screwed you that badly (and a short check should be sufficient to determine if they did if the distribution is popular!) you’re deeply screwed anyway. And there is nothing post-facto you can do from within that distribution.

For two years there was an undiscovered Debian-specific vulnerability in their OpenSSL package borking the generation of keys. But your point about being screwed from within applies to this case- regenerating the keys on an affected system would not have solved the problem, until it was patched. For those curious, look up ssh-vulnkey.

Following the guide's steps wouldn't have helped in the Debian case.

I reckon on average a distro ssh maintainer is more aware than an average end user following a hardening guide, even with mistakes like that one.

>Changing the server key protects you against the case that whoever made the distribution did it wrong

I'm unsure of ssh_host_* and it's importance, however on some hosts I manage the "ssh_host_rsa" key is only 2048 bits. Would regenerating "ssh_host_rsa" to be larger (4096 bits) not be an improvement?