Issue Report: Outdated/Redundant Material in SSH Hardening

[tartaruslovesnoodles]

https://github.com/decalage2/awesome-security-hardening/blob/master/README.md#services

Hello, I spotted some errors in your advising for SSH. I'll list what I noted below and make a fork.

These 3 sources referenced for SSH security no longer exist or may have been entered incorrectly.
https://www.ssi.gouv.fr/en/guide/openssh-secure-use-recommendations/
https://www.sshaudit.com/hardening_guides.html
https://bettercrypto.org/

This source listed below is deprecated by modern standards and contains 'expired' time bound advice.
https://goteleport.com/blog/how-to-ssh-properly/

• TOTP apps, while still used, are growing obsolete to hardware keys and push-based mfa.
• RSA keys are no longer the modern standard. This should be ssh-keygen -t ed25519.
• This article suggests extremely long lived certs, ie 1 year certs. This is far too long.
• While manual CA management is still something I'm personally not opposed to if it is done well, the article fails to mention vaults and the security tradeoffs many devs prefer with them opposed to manual setup.
• If you use a bastion host, then you either need to run it through a proxy (so you can add another bastion server if an issue arises but the whitelisted IP doesn't have to change) or have a backup bastion server that is also whitelisted. You don't want to have one failure point where failure will likely require a reboot or reinstall.
• Overall this article contains out of date advice and subpar practices. It is also redundant when paired with what you've already provided for SSH, providing no new information. Given all that, I'd suggest removing this article from the SSH section.

I'm not fully sure if this is the right place to post about this, apologies if it is not.

[yatinsayania]

SSH Security Guidance Review and Modernization

Introduction

As a cybersecurity consultant focused on infrastructure security and secure access management, I reviewed the SSH hardening guidance and associated references in the Services section. While the overall recommendations remain directionally sound, several references and implementation details no longer reflect current industry best practices. Updating these recommendations would improve both accuracy and long-term maintainability of the repository.

Analysis of Current Sources

The current SSH section references:

• https://www.ssi.gouv.fr/en/guide/openssh-secure-use-recommendations/
• https://www.sshaudit.com/hardening_guides.html
• https://bettercrypto.org/

These resources were valuable when originally published, but portions of their guidance have become outdated due to changes in OpenSSH defaults, cryptographic standards, authentication methods, and operational security practices.

Specific concerns include:

• Some cipher, MAC, and key-exchange recommendations are no longer relevant because modern OpenSSH releases already disable many legacy algorithms by default.
• BetterCrypto has seen limited maintenance activity and does not consistently reflect current OpenSSH releases.
• Several hardening recommendations overlap with existing OpenSSH secure defaults, creating unnecessary complexity for administrators.
• Some articles continue to emphasize TOTP-based MFA as a primary mechanism, whereas many organizations are moving toward phishing-resistant authentication.

Given these factors, it may be beneficial to remove redundant or outdated references and replace them with resources that track current OpenSSH releases and modern identity-management practices.

Modern SSH Security Recommendations

Recommended updates include:

• Prefer Ed25519 keys for user authentication:

ssh-keygen -t ed25519

• Consider FIDO2/WebAuthn security keys (for example, YubiKey-based SSH authentication) instead of relying solely on TOTP applications.
• Favor push-based MFA or hardware security keys over traditional TOTP where supported.
• Avoid long-lived SSH certificates such as one-year validity periods. Short-lived certificates measured in hours or days significantly reduce risk from credential compromise.
• Consider centralized SSH certificate authorities integrated with vault platforms, privileged access management solutions, or hardware security modules (HSMs) for enterprise environments.
• Continue disabling password authentication wherever practical and enforce public-key or certificate-based authentication.
• Implement SSH access logging, session monitoring, and key lifecycle management as part of a broader privileged access strategy.

Bastion Host Considerations

Bastion hosts remain a valid architectural pattern but should not become a single point of failure.

Recommended practices:

• Deploy redundant bastion hosts.
• Use load-balanced SSH proxy infrastructure where appropriate.
• Maintain backup access paths for operational continuity.
• Integrate bastions with centralized identity providers and access-control systems.
• Monitor and audit all privileged access traversing the bastion layer.

Suggested Actions

1. Remove or de-emphasize outdated SSH hardening references.
2. Add guidance for Ed25519 and FIDO2-based authentication.
3. Replace TOTP-focused recommendations with phishing-resistant MFA guidance.
4. Recommend short-lived SSH certificates rather than year-long validity periods.
5. Add enterprise-grade key management guidance using vaults, HSMs, or SSH certificate authorities.
6. Expand bastion host recommendations to include redundancy and high-availability considerations.
7. Eliminate duplicate guidance that is already covered by secure OpenSSH defaults, simplifying the documentation and improving maintainability.