On Wed, 12 Oct 2011, Tomas Mraz wrote:
Except nobody says or said that DNS without DNSSEC leads to the
automatic connection with such setting.
I answered that multiple times, including today with a vast amount of screen pasting
into
https://bugzilla.redhat.com/show_bug.cgi?id=180277 to show you that
DNS without DNSSEC does NOT lead to automatic connection in ANY case other then
you already having the key in known_hosts, which is the same behaviour as without
any SSHFP record in DNS.
The objection (upstream one that
is) is that setting VerifyHostKeyDNS yes ultimately sets you to depend
on the DNSSEC security for your SSH connection security
It does not add any new dependancies. If there is no DNSSEC, you are told the SSHFP
is in the DNS, shown the fingerprint like there is no SSHFP record, and asked if
you really want to continue. If there is DNSSEC, no entries to known_hosts are added
so whenever DNSSEC is not there, you fall back to exactly what you have now.
Also, ssh already "depends" on DNSSEC to get a trustworth A/AAAA record with an
RRSIG
from DNSSEC. The dependancy is there whether upstream likes it or not.
and that is
something we will never make default if upstream does not.
If upstream deems this so bad, why does upstream offer the option? I don't see them
offering 1des or rot13 cipher either. Apparently, upstream is somewhat divided?
Setting it to 'VerifyHostKeyDNS ask' by default is another
matter and I
am OK with that.
Thank you, it's good enough for me and a happy end of a 5 year old bug.
Paul