I am one of those people that think that StrictHostKeyChecking=yes
should be on by default for its security benefit, but obviously it's
a pain to connect to new nodes with this option turned on.

Hopeful, I was looking at VerifyHostKeyDNS for relief, but I found
none. No matter how I combine these options, I cannot reap any
benefit from fingerprints stored in DNS. See the following examples.

The first host does not have fingerprint information in DNS:

  % ssh -Snone -o StrictHostKeyChecking=yes -o VerifyHostKeyDNS=ask aika.krafftwerk.de uptime
  No RSA host key is known for aika.krafftwerk.de and you have requested strict checking.
  Host key verification failed.

This is precisely what I'd expect. But there is fingerprint data in
DNS for the next host, yet…:

  % ssh -Snone -o StrictHostKeyChecking=yes -o VerifyHostKeyDNS=ask diamond.madduck.net uptime
  No RSA host key is known for diamond.madduck.net and you have requested strict checking.
  Host key verification failed.

Couldn't it just say "hey, you wanted strict checking, but since
there's DNS info, I'll ask you and make your life a bit easier"?

For completeness, setting the two options to ask/yes (vs. yes/ask in the above)
yields the following:

  % ssh -Snone -o StrictHostKeyChecking=ask -o VerifyHostKeyDNS=yes diamond.madduck.net uptime
  The authenticity of host 'diamond.madduck.net (2001:470:b46d::1)' can't be established.
  RSA key fingerprint is SHA256:DiHbQd5xUBR9o0yDW3M6ZtbrOX945TKYPXXj3baAass.
  Matching host key fingerprint found in DNS.
  Are you sure you want to continue connecting (yes/no)? ^C

  % ssh -Snone -o StrictHostKeyChecking=ask -o VerifyHostKeyDNS=yes aika.krafftwerk.de uptime
  The authenticity of host 'aika.krafftwerk.de (2001:1620:2018:2::4d6d:8b5b)' can't be established.
  RSA key fingerprint is SHA256:N4lWu2fGy62l7T8KLTKnG41udQwkdFn0G321tNe/w3k.
  No matching host key fingerprint found in DNS.
  Are you sure you want to continue connecting (yes/no)? ^C

With ask/ask, it's exactly the same.

With no/ask and no/yes, the login just happens and the key gets added for both
hosts.

agreed
The default StrictHostKeyChecking isn't secure enough for you, but
you'd trust DNSSEC here? ;-P
I think the point here is the semantics of these two options, or rather
the semantics of OpenSSH in general:
AFAIU, it will generally only accept a remote key, when that's found in
one of the known_hosts files (or added automatically just now).
That's even the case for StrictHostKeyChecking=no - it just adds it
them automatically without asking.
And the same for VerifyHostKeyDNS, regardless of what you set there, it
wants the key in known_hosts.

No when you set StrictHostKeyChecking=yes and VerifyHostKeyDNS=ask|yes
the DNSSEC part would ask you whether to add the key (or add it
automatically in the yes case)... but since StrictHostKeyChecking=yes,
there is *NO* automatic adding of host keys.
And here that semantics kick in, that OpenSSH wants the host key in
known_hosts.

Well.. that's at least how I'd understand it, and the documentation
seem to back this.

Whether that behaviour makes sense or not is a different question:
The good thing on it is, that you have that guaranteed central place
where keys need to be in and that one option which controls whether
keys are ever auto-added to that file[0].

I guess the idea is to have some kind of a TOFU model... and that's why
each key (even when retrieved via DNSSEC) needs to go to known_hosts
first.
I hate TOFU[1], but well... it's not real TOFU, as you still have the
"trust path" via DNSSEC, 


Anyway... something like this should, if at all, only changed upstream,
so could you perhaps report/request it there?
But I would probably vote against it (not that I'd have any saying)...
and I'd guess upstream would either.
Actually I've already lobbied upstream to even do away with[0], but
that was rejected either.


Cheers,
Chris.


[0] Interestingly though, that's not completely true, even if
StrictHostKeyChecking=yes it will auto add entries to known_hosts with
the IP of a host, if that host has already a known key, say in
/etc/ssh/ssh_known_hosts, but under a domain name.
[1] http://www.metzdowd.com/pipermail/cryptography/2015-April/025342.ht
ml

also sprach Christoph Anton Mitterer <calestyo@scientia.net> [2015-11-12 17:41 +1300]:

Why should I not trust DNSSEC for hosts where I control the zone?

Well depends on what you mean by "control the zone":
If your resolver that verifies the DNSSEC has its starting trust anchor
for DNSSEC above your zone (i.e. at the root zone), every higher level
could in principle make forgeries.

But if you have your own keys configured as trust anchors in your
resolvers, than you're of course safe - but then I wouldn't see the big
advantage of using DNSSEC.

:-)

Cheers,
Chris.