Let's Talk About SSH Configuration Hardening...
A lot of administrators install the SSH service and assume its in top shape. What they don’t realize is that system packages tend to be optimized for compatibility, not security. While a lot of systems include defaults that are fine for most cases, there is still a lot of room for improvement–especially for high-security environments.
Depending on how old the package for your distribution is, the default configuration may have the following problems:
- Small host keys: 1024-bit RSA or DSA.
- Weak key exchanges: Diffie-Hellman groups using small 1024-bit moduli, or exchanges using deprecated hash algorithms like SHA-1.
- Vulnerable ciphers: 3DES, RC4, and SWEET32-vulnerable ciphers like Blowfish and CAST.
- MACs based on weak hash algorithms: MD5 or SHA-1.
As long as your users have reasonably modern SSH clients, you can fix all of the problems above without interoperability issues. And for those users who are lagging behind, well… chances are their client software has unpatched security problems anyway (note that 4 vulnerabilities have been fixed in PuTTY so far in 2017).
Ubuntu and RHEL Defaults
Let’s take a look at a fully-patched Ubuntu 16.04 LTS server. Its default config comes with a good selection of ciphers (chacha20-poly1305 is the default with backups using AES in CTR & GCM modes), but it supports some SHA-1 based algorithms for MACs and key exchange. Furthermore, its default RSA key is 2048-bit, which is equivalent to 112-bits of brute-force strength; to get 128-bits of security, this needs to be re-generated with a 3072-bit key. [1]
Things are much worse for RHEL/CentOS 6 (which is supported until 2024). Its default config supports 1024-bit Diffie-Hellman key exchanges (this is believed to be breakable by state-level adversaries! [2]), along with the weak RC4 cipher, Blowfish & CAST (both affected by the SWEET32 attack), as well as several MACs based on MD5 and SHA-1! Unless you take specific steps after installation, the RHEL/CentOS 6 SSH service is pretty abysmal.
Scanning Tools
The excellent (and open-source) ssh-audit tool will help you find problematic options enabled in your SSH service. But since not all admins are comfortable with command-line tools, I’ve gone ahead and written a web front-end to it for convenience, which also includes a comprehensive list of references for all discovered problems. You can find it here: https://www.sshaudit.com/
Hardening Guides
Stribik Andras wrote this excellent, general-purpose hardening guide in early 2015. While it does a great job in breaking down the different options available, it is slowly becoming out of date, and doesn’t take specific versions of OpenSSH into consideration (for example, newer versions of OpenSSH support DH Groups 16 & 18 from RFC3526, but a fully patched Ubuntu 16.04 LTS system uses a slightly older version that doesn’t include them). To compensate, I’ve written a set of guides specific to OS releases that optimize security for each platform.
You can find the improved hardening guides here: https://www.sshaudit.com/hardening_guides.html
References
[1] U.S. Department of Commerce, National Institute of Standards and Technology, “Special Publication 800-57, Part 1, Revision 4, Recommendation for Key Management, Part 1: General”, «http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf>>, Jan. 2016, pg. 53.
[2] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Beguelin, S., and Zimmermann, P., “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice”, «https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>>, Oct. 2015.