A system is only as secure as its weakest link. Given the proliferation of innovations in a constantly evolving IT landscape, it is easy to lose sight of fundamental requirements for network security, especially with regard to the Secure Shell (SSH) protocol. The original version of SSH, released at the end of 1995, took a revolutionary approach to securing Internet communications and really knocked its predecessor, Telnet, off its pedestal.

Since then, an even older protocol, HTTP, has been given a hierarchical trust model that enables secure interaction on any network. In contrast, SSH has not budged a single inch. Nevertheless, it remains an essential part of any Linux system and can still be found on virtually every Linux machine, despite its age of a good 25 years.

Security in Flux

SSH establishes the authenticity of its counterpart by the trust-on-first-use (TOFU) principle. According to RFC 4251 [1], TOFU is required to maintain a decentralized database (e.g., the text file known_hosts) on each SSH client that stores information about fingerprints and an SHA256 hash of the public key of trusted communication partners. SSH now checks this information for a match each time a connection to the same network identity is established. If the test fails, the user receives a plain text error message (Figure 1).

Figure 1: Error message for a faulty fingerprint.

In its day, this was a promising way to determine the integrity of servers. However, the parties involved have to verify the specified SHA256 hash mutually over a secure third channel to guarantee that the communication partner really is who they claim to be. With some manual work, this decentralized solution reliably validates the integrity of a connection.

Error messages are indicative of a spoofing attack, which still takes place on the web today. However, new, better ways can validate the authenticity of the parties involved. As the best possible compromise between security and convenience, people today use a public key infrastructure (PKI) in combination with certificates. SSH, on the other hand, has not proven itself to be a reliable protocol on the Internet and is now mostly used only on private networks.

That said, numerous servers with publicly accessible SSH ports can be found on the network, including Internet of Things (IoT) devices and virtual server and infrastructure providers. These ports make for particularly vulnerable targets for man-in-the-middle (MITM) attacks. Often, server identity verification is forgotten or ignored, resulting in a connection to an imposter. Mirrored SSH key pairs on rented servers are even more dangerous; attackers can extract and exploit them, which is why you should always regenerate the key pairs on such systems at the outset.

Man in the Middle

Like any other program, SSH is occasionally affected by vulnerabilities. For example, CVE-2020-14145 [2] allows an MITM attacker to hijack connections when they go through the TOFU process. The exploit describes an information leak when negotiating parameters while the connection is being established that allows the attacker to find out whether an OpenSSH client already has a stored fingerprint of its counterpart's public key. In most cases, such connections can be easily hijacked because the user usually accepts the fingerprint blindly without verification.

The cause of this information leak is the order of algorithms in the server_host_key_algorithms list, which is sent along during the exchange of parameters. Many SSH clients, including OpenSSH, place the preferred key creation algorithm for identifying the authentication key first, as per the requirements of the official SSH transport standard (RFC 4253) [3]. The listings differ depending on whether or not you know the fingerprint for the other party's public key.

Listing 1 compares two server_host_key_algorithms lists before and after an OpenSSH 8.3 client connects to the same server (i.e., with and without a known_hosts entry). As you can see, the server prefers an SSH RSA key. Public resources such as the ssh-mitm program (see the "ssh-mitm" box) can simplify the preparation of such information.

# Unknown Fingerprint
server key:
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519
rsa-sha2-512
rsa-sha2-256
ssh-rsa
# Known Fingerprint
server key:
rsa-sha2-512
rsa-sha2-256
ssh-rsa
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-ed25519

OpenSSH 8.4 implemented a small patch that fixes the information leak by using the default selected host key algorithm (ECDSA-SHA2) and placing it in the known_hosts file. The vulnerability can also be fixed either by specifying certain algorithms with the HostKeyAlgorithms option or by negotiating one of the certificate-based methods for authentication.

Why Secure SSH?

SSH is a special case because system administrators mainly use it on their own networks. Most of the time, they even use it in an isolated area that is specifically reserved for managing devices and can only be accessed over a virtual private network (VPN). A network like this only lets specialist personnel access a server's management interface.

So why do you need to secure SSH at all? The point is, in the worst case, to intercept an attacker even before they can grab shell access to critical systems. SSH access usually opens far-reaching possibilities and is therefore of particular interest to attackers. Accordingly, it definitely needs to be secured.

In environments where new hosts are frequently added or where a regular key renewal takes place to comply with security requirements, special attention should be paid to securing SSH access. A hijack with an MITM attack can easily occur here. Additionally, software tools that use SSH, such as Ansible, often offer an easy attack vector and are usually configured for convenience, so they do not strictly verify the host keys.

Companies that adhere to the information security guidelines of the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik , BSI; see the "National Security Agencies" box) regularly renew public and private key pairs. However, if SSH is integrated into this process, this would make any trust concept based on the TOFU principle obsolete. The integrity of the respective counterpart could no longer be determined if the keys were constantly renewed.