When connecting to a host using ssh, if I enter the full dns domain name of the host, then ssh correctly finds the host key fingerprint in DNS, and verifies that it is correct (eg "ssh server1.example.com") If I try to ssh to a server by just entering the hostname (eg "ssh server1") with no domain name, (and my /etc/resolv.conf contains the line "search example.com") then ssh connects to the server correctly, but it does NOT find the host key fingerprint in DNS. Doing a tcpdump on port 53 reveals that ssh attempts to look up the SSHFP entry in DNS without appending the default domain (even though it appends the default domain when attempting to look up the A record for the server). Tested on Debian Sarge and Sid, on i686.
Happens on ssh-5.1p1 on ubuntu jaunty as well. This greatly reduces the functionality of verifyhostkeydns since the very we are having to prevent (loading untrusted host keys) only works if users use the fqhn.
Unfortunately the resolver APIs don't give us any way to find out the canonical domain that the resolver actually used to find the address. There is a bit of discussion about this on openssh-unix-dev@mindrot.org (see the thread "Question about host certificates"). The workaround that I implemented was an easy way to apply a default domain name to unqualified host names in ssh_config: Host *.* Hostname %h Host * Hostname %h.my.domain It is a bit of a hack, but unfortunately it is the best we can do without changes to the resolver API.
With the release of OpenSSH 5.6p1 this bug is now considered closed. If you have further problems please reopen or file a new bug as appropriate.
While the comment that says this bug is fixed the commenter did not provide any other info so i cannot verify why this problem still exists in 5.6p1. Here is some output: karl@slap1:~$ cat /etc/resolv.conf domain corp.example.com search corp.example.com nameserver 10.13.0.133 options edns0 karl@slap1:~/openssh-5.6p1$ /nail/home/karl/ssh/bin/ssh -vvv -o VerifyHostKeyDNS=yes dsectest.corp.example.com OpenSSH_5.6p1, OpenSSL 0.9.8k 25 Mar 2009 <snip> debug2: ssh_connect: needpriv 0 debug1: Connecting to dsectest.corp.example.com [10.13.0.133] port 22. debug1: Connection established. <snip> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6p1 Debian-0ubuntu1 debug1: match: OpenSSH_5.6p1 Debian-0ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 <snip> debug3: verify_host_key_dns debug1: found 2 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS debug2: bits set: 522/1024 debug1: ssh_rsa_verify: signature correct <snip> debug1: Next authentication method: password karl@dsectest.corp.slide.com's password: karl@slap1:~/openssh-5.6p1$ /nail/home/karl/ssh/bin/ssh -vvv -o VerifyHostKeyDNS=yes dsectest OpenSSH_5.6p1, OpenSSL 0.9.8k 25 Mar 2009 <snip> debug2: ssh_connect: needpriv 0 debug1: Connecting to dsectest [10.13.0.133] port 22. debug1: Connection established. <snip> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6p1 Debian-0ubuntu1 debug1: match: OpenSSH_5.6p1 Debian-0ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 <snip> debug3: verify_host_key_dns DNS lookup error: name does not exist <snip> The authenticity of host 'dsectest (10.13.0.133)' can't be established. RSA key fingerprint is c4:1c:08:b5:25:35:53:5b:cc:13:9c:e9:db:43:6c:6a. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
I explained the workaround in comment #2
close resolved bugs now that openssh-5.9 has been released
The workaround in comment #2 only works for one domain. I have at least 3 domains in resolv.conf's search list: A site internal domain, our main domain, and a helper domain with CNAMEs for several parters' hosts. We already implemented a tool to distribute SSHFP records over any domain a host is listed in (i.e. World address, DMZ address) to solve the multi-IP resp. multi-interface problem. But in this state VerifyHostKeyDNS is useless for us ;-(
OpenSSH 6.5 introduce hostname canonicalisation options that will work for your case.
Thanks for commenting so fast in a closed issue. I can confirm the Canonical* options work for me, Thanks! A few details for whoever else may be led here by Google: In Debian wheezy, the wheezy-backports repository needs to be enabled to get 6.5. I trust DNS and CNAMEs because I have full control over our nameservers and I don't use other nameservers (except for DNS update penetration tests). Here are the Canonical options with default values (first mentioning of each option) and example values based on my ssh_config: #CanonicalDomains CanonicalDomains internal.site.mydomain.foo mydomain.foo partners.mydomain.foo #CanonicalizeFallbackLocal no CanonicalizeFallbackLocal yes #CanonicalizeHostname no #CanonicalizeHostname yes CanonicalizeHostname always CanonicalizeMaxDots 1 CanonicalizePermittedCNAMEs *.mydomain.foo:*