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.
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.
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).
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.
17 comments
[ 0.25 ms ] story [ 48.4 ms ] threadI 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!
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.
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.
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).