SSH-2, SFTP, SCP: how to achieve a perfect safety/security score...
SSH-2, SFTP, SCP: how to achieve a perfect safety/security score...
...and what are the trade-offs to be aware of.
Running an SSH-2 server, along with its typical subsystems, SFTP and SCP, is ultimately all about security. These services can provide file-transfer capabilities or even shell access to a remote host; therefore, it is crucially important to ensure their utmost safety and security.
Recently, a whole host of new vulnerabilities in the SSH-2 protocol, particularly in its most common implementation (OpenSSH), has drawn significant attention to the importance of securing these mission-critical services throughout the enterprise.
Tools have been developed to quickly and effectively assess the safety of these services. One such tool, which we find particularly well-designed, is ssh-audit.
Since the SSH-2 protocol (and therefore all of its subsystems) is designed to be highly modular and configurable, the same SSH-2 (or SFTP or SCP) service may be highly vulnerable or extremely safe, depending on how you configure it.
It goes without saying that any good System Administrator should strive to configure their SSH-2 services in the strongest possible manner. Ideally, this is what you’d want to achieve:
So, what is the exact set of security algorithms you need to achieve such a perfect safety and security score?
First and foremost, forget about RSA and ECDSA host keys. You need to deploy only and exclusively a single Ed25519 host key, as shown in the screenshot below:
Additionally, it is of paramount importance to ensure that none of your users use RSA or ECDSA keys for PKI authentication. Ed25519 is your go-to choice in this regard as well if you care about safety and security.
Next, you need to fine-tune all of the security algorithms that the SSH-2 (SFTP/SCP) protocol handler is allowed to use on your server. Here’s a quick recap:
MAC Algorithms
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
Encryption Algorithms
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
Key-Exchange Algorithms (Kex)
diffie-hellman-group16-sha512
diffie-hellman-group-exchange-sha256
curve25519@libssh.org
curve25519-sha256
Key Algorithms
ssh-ed25519
sk-ssh-ed25519@openssh.com
PKI Key Authorization Algorithms
ssh-ed25519
sk-ssh-ed25519@openssh.com
The above configuration will give you a perfect score in the ssh-audit test, but - as always when it comes to IT security - there is a trade-off.
The trade-off
You’ve probably noticed that some very common (yet extremely weak) algorithms are missing from the above lists. Remarkably, algorithms like ssh-rsa or ssh-dsa are nowhere to be found.
If you configure your SSH-2 (SFTP, SCP) server as explained above, you’ll likely start receiving angry emails from some users complaining they cannot connect/authenticate (log in) to your server anymore. They’re probably receiving error messages like “ssh: algorithm ‘ssh-rsa’ not accepted” (or similar).
This issue arises because their client is either old and only supports outdated and insecure algorithms, or it is simply configured to use those old algorithms even though it could be reconfigured to use better and safer ones.
We understand that no one likes the prospect of having to reconfigure many clients, but that’s the nature of IT security. Threats keep evolving, and one of the things threat actors exploit is the lack of application of these security updates, even when they are available.
There are a few, very few, narrow cases where the client-side cannot be reconfigured to utilize modern and secure algorithms (e.g., we encountered a 40-year-old IBM System 36 still in use by one of our customers), but these are very rare. In all other (common) cases, updating the server’s configuration and the corresponding client(s) is the preferred way to achieve the highest possible level of security.