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:

1

2

3

4

pi@ntp1:~$ssh lx.weberdns.de

The authenticity of host'lx.weberdns.de (2003:51:6012:110::9)'can'tbe established.

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 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-rname. 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.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

weberjoh@jw-nb12-lx:~$dig lx.weberdns.desshfp+dnssec+multi

;<<>>DiG9.10.3-P4-Ubuntu<<>>lx.weberdns.desshfp+dnssec+multi

;;global options:+cmd

;;Got answer:

;;->>HEADER<<-opcode:QUERY,status:NOERROR,id:48421

;;flags:qr rd ra ad;QUERY:1,ANSWER:9,AUTHORITY:0,ADDITIONAL:1

;;OPT PSEUDOSECTION:

;EDNS:version:0,flags:do;udp:4096

;;QUESTION SECTION:

;lx.weberdns.de.INSSHFP

;;ANSWER SECTION:

lx.weberdns.de.3589INSSHFP11(

1449B6B574092366759D72C3617FD69B6093B22E)

lx.weberdns.de.3589INSSHFP21(

CB0B8A83AB63F37D475A5B44F9558C96B65F4D91)

lx.weberdns.de.3589INSSHFP22(

5D1C30F734C6B1FFDC9F5C058245DB7B15591855CAB0

149508F58BF65DDFAFB9)

lx.weberdns.de.3589INSSHFP42(

4E125C92D0C3BF6162B3B253EA49A167C129B606C778

A1D5940BFDBAB0AE8668)

lx.weberdns.de.3589INSSHFP12(

9AD79ECDE76840AAD6C07DDDD8463F95F121029B9418

1786F6135FB817152835)

lx.weberdns.de.3589INSSHFP31(

0E91F83EDCE8BFC7C72D4E538C28D1BBCD66FB15)

lx.weberdns.de.3589INSSHFP41(

DF623280CBFFCE18F0BB37FC8864DF51FD3D7E90)

lx.weberdns.de.3589INSSHFP32(

F4C7F572AF9204A753F5842848743E8C18BA832B1CEE

8DF7D979E1217006282F)

lx.weberdns.de.3589INRRSIG SSHFP833600(

201609110953382016081208533857909weberdns.de.

p+r5oNKajiQXN/arL8nYtUCSGJ8kWOY/2ihxhNy/NOVB

MkOXQn6XI5+eEXzyl8S6y6rQ6Zc7cRXXlodyaaZGGPGc

vdtB+ooez7Nms2+q5t2qbpyjU/LJ9UF45iMc0cTMcJ6K

XuUNjjJ/pDLv8IJkURrYDSka3AGB2itdtAGdyd8=)

;;Query time:1msec

;;SERVER:192.168.120.22#53(192.168.120.22)

;;WHEN:Tue Aug3013:58:50CEST2016

;;MSG SIZE rcvd: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
VerifyHostKeyDNSoption from the OpenSSH client is not enabled by default. That is, a connection to an unknown server will still result in the following message:

1

2

3

4

weberjoh@jw-vm08-rdns:~$ssh lx.weberdns.de

The authenticity of host'lx.weberdns.de (2003:51:6012:110::9)'can'tbe established.

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

1

2

sudo nano/etc/ssh/ssh_config

VerifyHostKeyDNS yes

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 that the DNS reply is DNSSEC validated. If not, OpenSSH will get the SSHFP record (“Matching host key fingerprint found in DNS.”) but will still warn such as:

1

2

3

4

5

pi@ntp2:~$ssh-oVerifyHostKeyDNS=yes weberjoh@lx.weberdns.de

The authenticity of host'lx.weberdns.de (2003:51:6012:110::9)'can'tbe established.

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. (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:

1

2

3

4

weberjoh@jw-vm08-rdns:~$ssh-oFingerprintHash=sha256 lx.weberdns.de

The authenticity of host'lx.weberdns.de (2003:51:6012:110::9)'can'tbe established.

Now, with some online tools, this SHA256 fingerprint can be converted from base64 to hex, which then compares to the SSHFP records. 😉 Uff.

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: