The guide is outdated if you rely on the latest version of OpenSSH. You must update such guides with every new version of OpenSSH.

Adding legacy configuration to your OpenSSH config files can even result in a false sense of security (e.g., if the server/client just skip the legacy part and you think it adds some protection).

Newer options to secure OpenSSH are also missing (e.g., using U2F for 2FA, introduced in OpenSSH 8.2 (Feb 2020).

Are there any updated guides you’re aware of that you could share?

The ssh-audit tool is quite handy for making config recommendations in line with current best practice.

What are some other high quality “harden your server” guides? Many seem to be out of date

Compliance benchmarks like the other user suggests are probably best. eg: CIS

They're updated fairly regularly. However, take them with a grain of salt.

They'll worry about things like TCPWrappers, but that's how we did firewalls before they existed. Needless in the days of iptables, ebtables, nftables, etc.

Blogs tend to be recycled/dated recommendations with none/very little third party testing.

CIS workbenches are updated regularly. You have to sign up for an account, which is free, to get access.

Just keep in mind that some of the recommendations could've been dropped 20 to 30 years ago.

I don't disagree, they make some good suggestions - but take TCPWrappers for example. CIS will suggest you use it.

That predates firewalls, and requires applications be built/linked against the library.

These days, not worth the time/effort. Do the default-drop policy they suggest, and carry on!

It doesn't address the Trust On First Use (TOFU) issue.

A SSH Certificate Authority signing host keys handles that, but requires additional setup.

A quick and dirty way to do this is by syncing the known hosts file between all your clients. Make it writable by only the IT staff in charge of provisioning new systems and have them add the pubkeys during provisioning.

Add SSHP records to your DNS entries, and use DNSSEC or, if you can't, DoH (DNS over HTTPS)

> Mozilla Guidelines to Secure [Secure Shell]

Seems pretty reasonable, actually. Not as crazy as ATM Machine, since you can't have an ATM that isn't a machine, but you can have a Secure Shell that isn't secure.

Could also be a verb ("Guidelines [on how] to Secure Secure Shell") but even as an adjective it makes sense. "Guidelines to [a] Secure [setup of] Secure Shell" is a reasonable way to shorten that sentence, just like "Guide to [writing] Fast Java [code]" would be.

Secure Secure Shell?

It works. Secure is being used as a verb and SSH is being used as a noun. Mozilla guidelines to verb noun.

...to secure the thing known as "secure shell"