This is actually a bad user experience problem: To generally omit the manual verification of SSH key fingerprints I am using SSHFP. With fully qualified domain names (FQDN) as the hostname for SSH connections such as ssh nb10.weberlab.de this works perfectly. However, admins are lazy and only use the hostname without the domain suffix to connect to their servers since the domain search does the rest: ssh nb10. Not so for SSHFP which fails since the default OpenSSH client does not use canonicalization for its DNS queries. Hence you must explicitly enable canonicalization for OpenSSH.

SSHFP without Canonicalization

Note that this is not a DNS or DNSSEC “problem” but an OpenSSH default setting. The confusing point here is that OpenSSH uses the system resolver for querying the IP address of the host which uses the “search <domain>” statement within /etc/resolv.conf but does NOT use these settings for resolving the correspondent SSHFP resource records. Hence SSHFP fails such as:

Looking at the DNS traffic with tcpdump/Wireshark you can see that the AAAA/A IP addresses are answered due to the domain search list in /etc/resolv.conf (query: nb10.weberlab.de), but the query for SSHFP has no suffix at all since the OpenSSH program itself starts the DNS query nb10, which is answered with “no such name”:

Hostname Canonicalization in OpenSSH

Google found this great blog post for me. In short: You must enable “CanonicalizeHostname” and specify the “CanonicalDomains”. I am using exactly the same domains as in my  /etc/network/interfaces respectively /etc/resolv.conf files. Open the SSH client configuration file:  sudo nano /etc/ssh/ssh_config and add the following lines inside the Host * section: (In my use case I listed “weberlab.de”.)

Now the login prompt from SSH is coming directly since it actually could verify the fingerprints in the DNS again. Great!

When using the verbose option -v it shows the “Canonicalized hostname” and the DNS fingerprints:

Hence Wireshark reveals that even for the SSHFP record the FQDN of nb10.weberlab.de was queried and answered:

[Pitfall: Capturing with Prefilter]

By the way: I had several problems in capturing the DNS traffic with tcpdump on my Linux machine. I always used “port 53” as filter but never got the SSHFP DNS response. I really tried it a couple of times but never succeeded. Then I tried “not port 22” to see everything except my own SSH connection. And voilà, I got the DNS response. What has happened? The DNS response was to long to fit into a single UDP packet. Hence, IPv6 fragmentation was used which did not show up within the “port 53” filter from tcpdump. Arg! Tweeted:

Grr. Just failed in capturing DNS traffic with "port 53" tcpdump filter. Why? Because #IPv6 fragment is not "port 53". Took me 1 hour!!! pic.twitter.com/xepm0G9OTF

— Johannes Weber 🎸 (@webernetz) October 10, 2017

Featured image “Magnifier 2” by Dave Edens is licensed under CC BY-NC-ND 2.0.