SSH is a great protocol for protecting your assets over hostile networks; however, it is quite complex and over the years best practices have changed. Therefore, an SSH configuration that was once considered secure may no longer be so. In this post, we are going to go through steps and best practices to ensure your SSH configurations are secure, and details on how to test your existing configurations.
An Intro to SSH
SSH (also known as Secure Shell) has existed since 1995, it was invented as a secure alternative to the existing protocols, such as rlogin, TELNET, and FTP. There have been two major versions of the protocol; the original SSH server, which is now known as SSH-1, and in 2006 a SSH replacement known as SSH-2 that features both feature and security improvements. The most well-known implementation of SSH is OpenSSH, however many others exist.
Do you need remote access?
The first question to ask when securing an SSH server is do you need to expose this service over the Internet? While a well-configured SSH server provides good security, the security pattern of minimizing attack surface says that if something isn’t exposed it can’t be attacked. Instead would providing SSH access only via the corporate network or over VPN provide the access you need?
If access is needed over the internet consider implementing IP whitelisting to allow traffic only from trusted sources.
SSH Protocol Versions
SSH servers and clients may support either (or both) the SSH-1 and SSH-2 (A server that responds as version 1.99 is a SSH-2 server that supports SSH-1 for backwards compatibility). Only SSH-2 should be used, SSH-1 is now considered obsolete and should never be used.
Cipher selection for SSH is complex, there are multiple ciphers used for different stages of setting up the SSH connection (ciphers, KEX algorithms, MAC algorithms, and HostKey algorithms). Due to these complexities we are not going to provide recommended configs here, but instead direct you to Mozilla’s recommendation, which are being regularly updated:
A Secure Shell Fingerprint (SSHFP) Part of the SSH handshake is host identification, that is confirming a remote host is the host you wish to connect to before any sensitive information is passed. Most users of SSH use it in a trust on first use pattern, they accept the identification the first time they connect to an SSH server, and the SSH client caches this information for future uses. If someone tries to spoof the SSH server after this point the SSH client will alert the user. However, this has its weaknesses, for example, if the use is part of a man-in-the-middle attack, or if a user needs to access the SSH service from a new device.
The alternative to this is to pre-distribute the authentication checksums and validate on initial login. This can be done by placing the keys on a website and using the SSL/TLS certification system for validity. This provides good protection but is quite a manual process.
Alternatively, SSHFP can be used; SSHFP uses DNS records to distribute the SSH checksums. Support for SSHFP is built into many SSH clients (though may need to be enabled) and the client will automatically retrieve and verify the checksum. This is probably the best method; however, it does require DNSSEC to be enabled to ensure chain of trust.
SSH provides several options for authentication, including password-based authentication and certificate-based, as well as having support for multi-factor authentication. By default, most SSH servers have password authentication enabled; SureCloud would recommend disabling password-based authentication and using certificated-based instead. Certificate-based authentication has several advantages over passwords, such as not being vulnerable to password guessing attacks. Details on configuring certificate-based authentication are beyond the scope of this post, however, there are many good articles on this subject.
If password authentication is needed there are systems that can be implemented to help to mitigate the risks and to help prevent password guessing attacks. One of the best known of which is Fail2Ban, which can blacklist attackers. https://www.fail2ban.org/wiki/index.php/Main_Page
Disable Root Login
Most SSH servers allow root login by default, SureCloud would recommend disabling this via the SSH config, for OpenSSH this is done by setting this following directive which is usually found in /etc/ssh/sshd_config:
If privileged access is required over SSH privilege escalation should be performed after login through mechanisms, such as sudo.
SSH clients will need their own configuration hardening. They should be configured only to use SSH-2, and to only support Ciphers that are considered strong. Mozilla provides best practice configuration examples for OpenSSH:
The SureCloud platform can test your SSH services, alternatively, there are a few excellent tools that can help you to audit your SSH config.
Mozilla provides a tool, written in Ruby that can provide detailed best practice reports on remote SSH servers.
SSHScan is an alternative tool, written in python, that provides similar feedback on SSH weaknesses including weak cipher support.
Author Martin Ellis, Cybersecurity Consultant for SureCloud.
Find out more about our Cybersecurity services here.
SureCloud provides Governance, Risk & Compliance (GRC) applications and Cybersecurity services that give our customers certainty – of risk management/compliance, of cybersecurity, of having answers today and tomorrow. Established in 2006, SureCloud is headquartered in the United Kingdom and has offices in the United States. SureCloud has more than 400 customers throughout the UK and US from the Retail, Financial Services, Government and other sectors.