Lead Image © Olivier Le Moal, 123RF.com

Lead Image © Olivier Le Moal, 123RF.com

Secure SSH connections the right way

Certified

Article from ADMIN 66/2021
By
Admins use SSH, the proverbial Swiss army knife of system management, for many of their daily tasks, but no matter how powerful the tool might be, it typically does not offer adequate protection. We look at ways to tighten SSH security.

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.

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

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Attacks on HTTPS Connections
    HTTPS protects a connection from both tapping and manipulation, but only if a man in the middle hasn't already infiltrated the Internet connection. We highlight the weaknesses in HTTPS and demonstrate how to protect your client and server.
  • Hardening network services with DNS
    The Domain Name System, in addition to assigning IP addresses, lets you protect the network communication of servers in a domain. DNS offers further hardening of network protocols – in particular, SSH fingerprinting and CAA records.
  • SSL/TLS best practices for websites
    SSL and TLS are very complex technologies. If you want to avoid wading through cryptography manuals to harden your HTTPS web server, read on for practical recommendations on establishing, securing, and optimizing your SSL/TLS configuration.
  • Transport Encryption with DANE and DNSSEC
    Those who think that enabling STARTTLS in the mail client will make their mail traffic more secure are wrong. Only those who bank on DANE can be sure that a mail server or a firewall will not switch off encryption in transit.
  • Secure your data channel with stunnel
    Stunnel provides a TLS wrapper with extensive configuration options to secure your data over insecure wireless networks.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=