SSHFP: Authenticate SSH Fingerprints via DNSSEC

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:

pi@ntp1:~ $ sshlx.weberdns.de Theauthenticityofhost 'lx.weberdns.de (2003:51:6012:110::9)' can't beestablished. ECDSAkeyfingerprintis 49:f7:d1:ea:2c:4c:f8:0a:5b:26:08:b2:ce:7d:bb:76. Areyousureyouwantto continue connecting (yes/no)? ^C

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… :wink: 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:

weberjoh@jw-nb12:~$ ssh-keygen -r lx lxIN SSHFP 1 1 1449b6b574092366759d72c3617fd69b6093b22e lxIN SSHFP 1 2 9ad79ecde76840aad6c07dddd8463f95f121029b94181786f6135fb817152835 lxIN SSHFP 2 1 cb0b8a83ab63f37d475a5b44f9558c96b65f4d91 lxIN SSHFP 2 2 5d1c30f734c6b1ffdc9f5c058245db7b15591855cab0149508f58bf65ddfafb9 lxIN SSHFP 3 1 0e91f83edce8bfc7c72d4e538c28d1bbcd66fb15 lxIN SSHFP 3 2 f4c7f572af9204a753f5842848743e8c18ba832b1cee8df7d979e1217006282f lxIN SSHFP 4 1 df623280cbffce18f0bb37fc8864df51fd3d7e90 lxIN SSHFP 4 2 4e125c92d0c3bf6162b3b253ea49a167c129b606c778a1d5940bfdbab0ae8668

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.

weberjoh@jw-nb12-lx:~$ diglx.weberdns.de sshfp +dnssec +multi ; <<>> DiG 9.10.3-P4-Ubuntu <<>> lx.weberdns.de sshfp +dnssec +multi ;; globaloptions: +cmd ;; Gotanswer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48421 ;; flags: qrrdraad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPTPSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTIONSECTION: ;lx.weberdns.de.IN SSHFP ;; ANSWERSECTION: lx.weberdns.de.3589 IN SSHFP 1 1 ( 1449B6B574092366759D72C3617FD69B6093B22E ) lx.weberdns.de.3589 IN SSHFP 2 1 ( CB0B8A83AB63F37D475A5B44F9558C96B65F4D91 ) lx.weberdns.de.3589 IN SSHFP 2 2 ( 5D1C30F734C6B1FFDC9F5C058245DB7B15591855CAB0 149508F58BF65DDFAFB9 ) lx.weberdns.de.3589 IN SSHFP 4 2 ( 4E125C92D0C3BF6162B3B253EA49A167C129B606C778 A1D5940BFDBAB0AE8668 ) lx.weberdns.de.3589 IN SSHFP 1 2 ( 9AD79ECDE76840AAD6C07DDDD8463F95F121029B9418 1786F6135FB817152835 ) lx.weberdns.de.3589 IN SSHFP 3 1 ( 0E91F83EDCE8BFC7C72D4E538C28D1BBCD66FB15 ) lx.weberdns.de.3589 IN SSHFP 4 1 ( DF623280CBFFCE18F0BB37FC8864DF51FD3D7E90 ) lx.weberdns.de.3589 IN SSHFP 3 2 ( F4C7F572AF9204A753F5842848743E8C18BA832B1CEE 8DF7D979E1217006282F ) lx.weberdns.de.3589 IN RRSIGSSHFP 8 3 3600 ( 20160911095338 20160812085338 57909 weberdns.de. p+r5oNKajiQXN/arL8nYtUCSGJ8kWOY/2ihxhNy/NOVB MkOXQn6XI5+eEXzyl8S6y6rQ6Zc7cRXXlodyaaZGGPGc vdtB+ooez7Nms2+q5t2qbpyjU/LJ9UF45iMc0cTMcJ6K XuUNjjJ/pDLv8IJkURrYDSka3AGB2itdtAGdyd8= ) ;; Querytime: 1 msec ;; SERVER: 192.168.120.22#53(192.168.120.22) ;; WHEN: TueAug 30 13:58:50 CEST 2016 ;; MSGSIZErcvd: 534

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:

weberjoh@jw-vm08-rdns:~$ sshlx.weberdns.de Theauthenticityofhost 'lx.weberdns.de (2003:51:6012:110::9)' can't beestablished. ECDSAkeyfingerprintis SHA256:T09/p/ZSubnkraG3oslDMehfIiLRe6UiVn1dGZvtjZE. Areyousureyouwantto continue connecting (yes/no)? ^C

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

weberjoh@jw-vm08-rdns:~$ ssh -o VerifyHostKeyDNS=yesweberjoh@lx.weberdns.de weberjoh@lx.weberdns.de's password:

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

sudonano /etc/ssh/ssh_config VerifyHostKeyDNSyes

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.

Note that it is crucial t