Secure SSH connections the right way


Securing SSH the Right Way

To accommodate requirements such as a regular key renewal, many system administrators seek a solution that balances integrity and scalability. To guarantee the integrity of a server without triggering a manual verification procedure over a secure third channel, OpenSSH offers to validate the counterpart with SSH fingerprint (SSHFP) Domain Name System (DNS) entries. These entries use a DNS server's zone file to store a fingerprint of a network identity's public key, which serves as a trusted third source. Therefore, it is important to secure the integrity of the DNS server with DNS Security Extensions (DNSSEC).

SSHFP DNS records follow a special format and can be generated for a specific host name with the ssh-keygen command (Listing 2). The admin then enters the output in a DNSSEC-signed zone file so that SSH clients can query the data securely.

Listing 2


# ssh-keygen -r -f /etc/ssh/
 IN SSHFP 3 1 2e99e82cb06d646039fb813242850f69a4fc2c67 IN SSHFP 3 2 fbfb8965a367f71e4ed8f6737a2e2db1c04be671db7c9c4e17ac346b9ae7a825

With the SSH option VerifyHostKeyDNS=yes set, SSH clients compare the supplied fingerprints with those in DNS. The DNS server's response needs to be DNSSEC-signed; otherwise, SSH requires manual verification of the fingerprint because it can no longer guarantee the integrity of the entry. SSHFP DNS entries do not directly prevent the SSH information leak, but they reliably prevent MITM attacks.

This approach also enables automatic verification of server fingerprints. Key renewal is not directly part of this process but could be included automatically with some additional configuration work. This solution is particularly useful for providers who want to offer their customers SSH access to rented hosts. It only requires a public and signed domain and a few entries in the zone file to guarantee that customers can communicate with their servers securely.

Proprietary Certificates

A public key infrastructure (PKI) in combination with certificates is recommended for everyone who needs a central key management system capable of ensuring the integrity of servers and clients. Because OpenSSH does not support the widely used X.509 certificates, you need to use a PKI structure in combination with digitally signed keys, expiration dates, and identity assignments.

An environment presupposes that name resolution is in place with identities for all servers within the domain to be managed. The first step is to set up a root Certification Authority (CA) on the basis of OpenSSH proprietary certificates, which acts as a trust foundation and signs the certificates of the individual servers. The corresponding key pair can be generated with the command:

ssh-keygen -t rsa -f ca_root_key

Certificates are signed with the private key by the CA and then distributed to the individual hosts. Server certificates are best stored in /etc/ssh/<Host> and client certificates in ~/.ssh/. The SSH program automatically uses the latter file if they have the suffix.

Issuing a host certificate differs, as you can see from Listing 3, in terms of the -h parameter. The duration can be set with -V; in this example, the certificate would need to be renewed before six months have passed. The -n argument takes a list of principals that determine the identities of the certificate. For host certificates, these principals should correspond to the domain name and IP address. For client certificates, they are used to assign identities so that you can determine access rights on the server side. Listing 4 shows what a certificate of this type could look like.

Listing 3

Generating Certificates

$ ssh-keygen -s ca_root_key -h -n, -I -V +180d
$ ssh-keygen -s ca_root_key -n -I -V +180d

Listing 4

Displaying an OpenSSH Certificate

[root@server ssh]# ssh-keygen -L -f /etc/ssh/
  Type: host certificate
  Public key: RSA-CERT SHA256:uJbAVibJhbFXr0z5l0i/O08/fOwMq+JGbCDqz+/PJ7s
  Signing CA: RSA SHA256:vIQWA43cZ4b6DEexmOSvtUG0wNFGF/opWQ75lzbwRRs
  Key ID: ""
  Serial: 0
  Valid: from 2021-02-18T03:25:00 to 2021-08-17T04:26:39

  Critical Options: (none)
  Extensions: (none)

Listing 5 shows the server configuration. The first line specifies the installed host certificate. The other two lines allow you to limit access. TrustedUserCAKeys specifies that CA-validated certificates can access the local system through the public key. To specify more granular access authorizations, an additional AuthorizedPrincipalsFile can be specified to restrict access to specific principals.

Listing 5

Certificate Entries in sshd_conf

HostCertificate /etc/ssh/
TrustedUserCAKeys /etc/ssh/
AuthorizedPrincipalsFile /etc/ssh/auth_principals

On clients that you want to establish a trust relationship with the CA, you need the entries from Listing 6 in the known_hosts file.

Listing 6

CA entries in known_hosts

@cert-authority * ssh-rsa <PublicKey>
@cert-authority 172.16.155.* ssh-rsa <PublicKey>

A complete PKI also needs a way to revoke the validity of certificates. To do this, you use the command

$ ssh-keygen -k -f revoked_keys -s

to create a key revocation list file for the CA and then publish the list. Clients now need to reference a local version of the list with the RevokedHostKeys option and servers with the RevokedKeys configuration. In this way, revoked certificates can be detected.

Now any computer that trusts this CA can verify the identity of its counterpart, which means that warnings about false certificates or signatures become more important once again and should be taken seriously, just as they are on the Internet. You need to keep the root CA key pair as secure as possible because if it is compromised all of the certificates signed by it are no longer trustworthy.

The approach presented here not only provides protection against MITM attacks but also negates all CVE-2020-14145 scenarios.

For and Against

Although an internally deployed PKI plays to its strengths in central key and integrity management, it also has disadvantages. Above all, a separate solution for OpenSSH requires a great deal of additional configuration overhead compared with other PKI structures if it is to operate automatically.

In general, operating a PKI involves major overhead because processes such as the automatic renewal of certificates need to be implemented. However, this drawback is offset by the advantage that admins can control SSH directly through the certificates. For example, it is possible to prevent port forwarding at a program level.

Buy this article as PDF

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

Buy ADMIN Magazine

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