This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:

The Problem

If you are an SSH admin you definitely know the following message:

You are connecting to an SSH server the first time and you get the “can’t be established” message. And we all know: Nobody ever checks this fingerprint against a manually distributed list of fingerprints… ;) That is: If the first attempt to a new SSH server is spoofed by a man-in-the-middle attack (or a next-generation firewall with SSH decryption), you won’t recognize it!

The Solution: SSHFP

A technical solution to overcome this “whom can you trust” problem is the secure distribution of SSHFP (Secure Shell Key Fingerprints) within the Domain Name System (DNS). If the authoritative DNS server is signed via DNSSEC, the connecting SSH client can securely verify/authenticate the fingerprint of the SSH server it is connecting to.

The standard is defined in RFC 4255 “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints” and RFC 6594 “Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records” and RFC 7470 “Using Ed25519 in SSHFP Resource Records”. The DNS SSHFP Resource Record Parameters are listed by IANA.

The only required step is to distribute the SSH fingerprints within the DNS. To accomplish this, the fingerprints must be generated/listed on the SSH server itself via the ssh tool  ssh-keygen -r name. This lists the fingerprints for all available public key algorithms (RSA, DSA, ECDSA, Ed25519) in SHA1 and SHA256:

After these records are placed into the DNS server zone (and signed via DNSSEC), they can be queried and validated via DNSSEC. Note the “AD” flag for authentic data within the DNS header. There is only one RRSIG record since all SSHFP records are signed at once.

An SSH client that is configured to check the SSHFP record is now able to verify the fingerprint. If this client furthermore gets authentic data (DNSSEC validated “AD” flag), it will silently connect to the SSH server since it was able to authenticate the server. Great!

Tests

Currently, the  VerifyHostKeyDNS option from the OpenSSH client is not enabled by default. That is, a connection to an unknown server will still result in the following message:

But when used with the -o VerifyHostKeyDNS=yes option, it will not warn about an unauthenticated server, because it IS authenticated now:

Using the -v flag you can see the following two lines that reveal that (1) SSHFP records are found in DNS (called “secure fingerprints” because DNSSEC is used), and (2) that they match the host key from the server:

Of course, this option can/should/must be set in the global ssh config, too:

This is great at all! Customers that have many servers and firewalls placed around the world can now connect from a jump host to any of them without the fear of man-in-the-middle decrypted SSH sessions. Yeah.

Test without DNSSEC Validation

Note that it is crucial that the DNS reply is DNSSEC validated (= “ad” flag when testing with dig). If not, OpenSSH will get the SSHFP record (“Matching host key fingerprint found in DNS.”) but will still warn such as:

Using the -v flag again, you can see some “insecure fingerprints“:

MD5, SHA256, Hex, Base64

What? “Why is the SSHFP fingerprint not the same as the log message from ssh?” This question took my a while to fully understand. And I am not the only one (click, click). In fact, there are several options to display fingerprints, e.g., with MD5, SHA256, either in hexadecimal or base64 notation. OpenSSH displays the fingerprint in MD5-hex or SHA256-base64 notation by default, whereas the SSHFP records list the SHA1 and SHA256 fingerprints, each in hex notation. That is: they are mutually exclusive. And since each of the four possible public keys (RSA, DSA, ECDSA, Ed25519) has its own fingerprint you’ll probably have MANY different fingerprints at all. ;) (Refer to OpenSSH/Cookbook/Authentication Keys. “The fingerprint can be forced to display as an MD5 hash in hexadecimal instead by passing FingerprintHash configuration directive as a runtime argument or in ssh_config. But the default is now SHA256 in base64. […] In OpenSSH 6.7 and earlier this fingerprint was a hexadecimal MD5 checksum instead a of the base64-encoded SHA256 checksum currently used.”)

The output of the fingerprint can be set to other hash algorithms, such as:

Now, with some online tools, this SHA256 fingerprint can be converted from base64 to hex, which then compares to the SSHFP records. ;) Uff. That is: The the ECDSA fingerprint in SHA-256 in the hex variant (beginning with “4f:4f:7f” as seen in the SSHFP type 3 2 record) is the correct one as in the base64 variant (beginning with “T09/”).

What about PuTTY?

Unfortunately PuTTY is not supporting SSHFP yet. :( It is on the wishlist a few years now, but still not supported. Of course this is bad since many admins are using Windows machines with PuTTY to manage Linux servers. However, if a central (Linux) jump server is used for connecting to all other servers/firewall/routers/whatever, SSHFP is still very useful.

As a small workaround I placed a TXT record for my Linux server on the DNS to be able to compare the fingerprint with the ssh message, such as:

Of course this is no automatic security, but at least I can manually check whether I am talking to the correct server. (But, you know, I won’t…)

Featured image “print” by jim hutchison is licensed under CC BY-NC-ND 2.0.