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).
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.
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.
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.
[+] [-] infosechandbook|4 years ago|reply
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).
[+] [-] skoskie|4 years ago|reply
[+] [-] cosentiyes|4 years ago|reply
[+] [-] bravetraveler|4 years ago|reply
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.
[+] [-] igetspam|4 years ago|reply
[+] [-] markmaglana|4 years ago|reply
[+] [-] zdw|4 years ago|reply
[+] [-] franga2000|4 years ago|reply
[+] [-] csdvrx|4 years ago|reply
[+] [-] fnord123|4 years ago|reply
[+] [-] franga2000|4 years ago|reply
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.
[+] [-] shmoe|4 years ago|reply
[+] [-] soneil|4 years ago|reply
[+] [-] 0xdeadb00f|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]