#896145 Wrong DNS resolving for SSHFP lookup

Package:
openssh-client
Source:
openssh
Description:
secure shell (SSH) client, for secure access to remote machines
Submitter:
Uwe Kleine-König
Date:
2026-02-06 18:53:02 UTC
Severity:
normal
#896145#5
Date:
2018-04-20 08:08:25 UTC
From:
To:
Hello,

I have on my work machine

	VerifyHostKeyDNS ask

in my ~/.ssh/config and

	search mydomain

in /etc/resolv.conf (anonimized though).

With

	tcpdump -i $landev udp port 53

running on my local DNS server, I see the following requests logged when I do

	ssh anothermachine

from my work machine:

07:52:23.446609 IP work.mydomain.53992 > dnsserver.mydomain.53: 64011+ A? anothermachine.mydomain. (47)
07:52:23.446741 IP work.mydomain.53992 > dnsserver.mydomain.53: 59411+ AAAA? anothermachine.mydomain. (47)
07:52:23.447450 IP dnsserver.mydomain.53 > work.mydomain.53992: 64011* 1/0/0 A 192.168.0.12 (63)
07:52:23.447762 IP dnsserver.mydomain.53 > work.mydomain.53992: 59411 0/0/0 (47)
07:52:23.504582 IP work.mydomain.57475 > dnsserver.mydomain.53: 36966+ [1au] SSHFP? anothermachine. (34)
07:52:23.507386 IP dnsserver.mydomain.53 > work.mydomain.57475: 36966* 0/0/1 (34)

The request for "anothermachine.mydomain." can be replied by my local
DNS server directly, the request "anothermachine." however is forwarded
to the next upstream DNS server and so my intend to connect is leaked.

I would expect that ssh asked for "SSHFP? anothermachine.mydomain."
instead of "SSHFP? anothermachine." in this case.

I didn't check the code, but I think the fix includes to add
AI_CANONNAME to hints.ai_flags in the call to getaddrinfo(3) and use
the returned ai_canonname for looking up the SSHFP DNS RR.

Best regards
Uwe

#896145#10
Date:
2026-02-06 18:51:34 UTC
From:
To:
I also did notice this few days ago.

When connecting using FQDN it works.

Matching host key fingerprint found in DNS.

But if I use shortname, (and it still resolves, because I have search
list setup) to the same IP, the ssh client says:

DNS lookup error: name does not exist    # when running with -v

No matching host key fingerprint found in DNS.


The truth is this is probably an issue in libc getaddrinfo design, which
does not return canonical name back after finishing resolving.