A change in ssh's SSHFP-related behavior on current confuses me somewhat.
I've set VerifyHostKeyDNS to 'ask' in /etc/ssh/ssh_config (before and
after the observed change in behavior).
Previously, ssh client always kept quiet in case the ssh host key is
already known (from known_hosts).
Now, ssh client also asks "Are you sure you want to continue
connecting?" in case no SSHFP DNS records has been supplied via DNS at
all, even when the server's HostKey is already known from known_hosts.
In particular, I find this annoying when I use short hostnames on the
LAN instead of FQDNs, e.g.,
"ssh user@host" (which resolves to host.domain.name due to a 'domain
domain.name' entry in /etc/resolv.conf. However, ssh seems to directly
ask for the SSHFP record 'host.' which doesn't exist in local DNS)
instead of
"ssh u...@host.domain.name" (works without problems)
From my point of view, the expected behaviour of ssh would be to not
explicitly ask the user in case the HostKey is already known from
known_hosts (i.e., like it was before the observed change in behavior).
It should probably also ask in case there is an actual SSHFP fingerprint
mismatch, but not in case an SSHFP record is not supplied at all.
Regarding the first example from above, I guess ssh should directly ask
for the SSHFP record of host's FQDN (host.domain.name) instead of the
hostname (host.).
Best regards
Andreas
