I am intensely using the SSH Public Key Fingerprint (SSHFP, RFC 4255) in all of my environments. Since my zones are secured via DNSSEC I got rid of any “authenticity of host ‘xyz’ can’t be established” problems. As long as I am using my central jump host with OpenSSH and the “VerifyHostKeyDNS yes” option I can securely login into any of my servers without any warnings. Great!
However, I encountered a couple of daily problems when using SSHFP. One of them was the question whether SSHFP works behind CNAMEs, that is, when connecting to an alias. Short answer: yes. Some more details here:
The usage of SSHFP even works when connecting to an alias. Here is an example: I am running a workstation with the name nb10.weberlab.de. And of course I have added SSHFP records for this name. Furthermore I have another DNS alias called mirror.weberlab.de which points to the CNAME nb10.weberlab.de.
mirror CNAME nb10
nb10 AAAA 2001:db8::
nb10 SSHFP deadbeef...
Now I am using SSH to connect to the alias at mirror.weberlab.de. This works without any errors because the SSH client uses the AAAA record as well as the SSHFP records from the real machine behind the CNAME record. This is how ssh looks like:
weberjoh@nb15-lx:~$ ssh -v mirror.weberlab.de
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:NNA1u1ypjwlyPTZMfK/RxuM4z0BMeca+GLnoAAS/yY4
debug1: found 6 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
Using dig to query the SSHFP records for the alias shows them as well:
weberjoh@nb15-lx:~/.ssh$ dig mirror.weberlab.de sshfp
; <<>> DiG 9.10.3-P4-Ubuntu <<>> mirror.weberlab.de sshfp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61850
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 3, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mirror.weberlab.de. IN SSHFP
;; ANSWER SECTION:
mirror.weberlab.de. 86216 IN CNAME nb10.weberlab.de.
nb10.weberlab.de. 86217 IN SSHFP 1 2 5F2F221CFF0C5059E6A616302E941A99BE22AE3D2980628E00E90B38 AA809559
nb10.weberlab.de. 86217 IN SSHFP 3 2 34D035BB5CA98F09723D364C7CAFD1C6E338CF404C79C6BE18B9E800 04BFC98E
nb10.weberlab.de. 86217 IN SSHFP 3 1 C4A709C005C2AEB1AE793A1E98B090ED129EBF73
nb10.weberlab.de. 86217 IN SSHFP 2 1 622CC93FB1632208F5C3C74851A3A5C2B63E45C7
nb10.weberlab.de. 86217 IN SSHFP 1 1 37876053E0242066793D742E9164F20A40F18F24
nb10.weberlab.de. 86217 IN SSHFP 2 2 356CCB10B0E24AFA722395A21D8C52FCE4A803207740A6032E078A62 C71E61FD
;; Query time: 2 msec
;; SERVER: 2003:de:2016:120::a08:53#53(2003:de:2016:120::a08:53)
;; WHEN: Tue Oct 10 15:21:28 CEST 2017
;; MSG SIZE rcvd: 445
Capturing the DNS requests from SSH with tcpdump/Wireshark you can see queries for AAAA/A records which are answered with CNAME and the actual IPv6 address, as well as the query for SSHFP which is answered with the CNAME and SSHFP records, too. All responses are authenticated by the server (ad flag):
This works out of the design from DNS itself since “the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record”, RFC 1034, section 3.6.2. That is: independent of the initial query type (AAAA or SSHFP) the DNS resolver answers with the CNAME record as well as with the queried record type. Hence the SSH client accepts the IP address along with the SSHFP.
Featured image “<- ALIAS” by Steffi Reichert is licensed under CC BY-NC-ND 2.0.