Secure SSH connections the right way
Certified
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).
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.
Listing 1
Algorithm Lists
# 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
ssh-mitm
The ssh-mitm
[4] program supports security monitoring and lets you monitor your own SSH traffic. The developers want to highlight and draw attention to the risks and problems of the SSH protocol. I contribute to this project as a programmer and have implemented many of the security monitoring features, one of which is detection of the CVE-2020-14145 SSH information leak.
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.
National Security Agencies
Every year, the German Federal Office for Information Security publishes several documents that address general information security in a company. The BSI standards and a summarized version, the IT-Grundschutz (Basic Protection) Compendium [5], serve as public information security guidelines for many companies because they are very close to the requirements of ISO 27001 IT management certification [6].
Other countries have similar agencies for information security, including the Computer Security Division (CSD) of the Information Technology Laboratory (ITL) within the National Institute of Standards and Technology (NIST) in the United States, the Communications-Electronic Security Group (CESG) of the United Kingdom, and the National Cybersecurity Institute (INCIBE) in Spain.
Buy this article as PDF
(incl. VAT)