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.

# ssh-keygen -r server.example.com -f /etc/ssh/ssh_host_ecdsa_key.pub
server.example.com
 IN SSHFP 3 1 2e99e82cb06d646039fb813242850f69a4fc2c67
server.example.com 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>-cert.pub and client certificates in ~/.ssh/. The SSH program automatically uses the latter file if they have the -cert.pub 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.

$ ssh-keygen -s ca_root_key -h -n server.example.com,172.16.155.130 -I server.example.com -V +180d server.example.com
$ ssh-keygen -s ca_root_key -n client.example.com -I client.example.com -V +180d client.example.com

[root@server ssh]# ssh-keygen -L -f /etc/ssh/server.example.com-cert.pub
/etc/ssh/server.example.com-cert.pub:
  Type: ssh-rsa-cert-v01@openssh.com host certificate
  Public key: RSA-CERT SHA256:uJbAVibJhbFXr0z5l0i/O08/fOwMq+JGbCDqz+/PJ7s
  Signing CA: RSA SHA256:vIQWA43cZ4b6DEexmOSvtUG0wNFGF/opWQ75lzbwRRs
  Key ID: "server.example.com"
  Serial: 0
  Valid: from 2021-02-18T03:25:00 to 2021-08-17T04:26:39
  Principals:
          server.example.com
          172.16.155.130
  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.

HostCertificate /etc/ssh/server.example.com-cert.pub
TrustedUserCAKeys /etc/ssh/ca_root_key.pub
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.

@cert-authority *.example.com ssh-rsa <PublicKey> root@ca.example.com
@cert-authority 172.16.155.* ssh-rsa <PublicKey> root@ca.example.com

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 ca_root_key.pub client.example.com

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.