Request to please enable VerifyHostKeyDNS for openssh-clients in FC7

[Michael Stahnke]

I would also vote to enable it.  It is a great security feature at
almost no cost to the end-user.

Mike Stahnke

On 3/23/07, Paul Wouters <paul at xelerance.com> wrote:
> On Fri, 23 Mar 2007, nodata wrote:
>
> > Can I check something? Is SSHFP not useful unless dnssec is on?
>
> It is still very much useful.
>
> First of all, in the case of a trusted network, say a big university campus.
> Using sshfp records, administrators can add new machines to the network and
> put their sshfp records in DNS. You will be able to trust the keys for those
> machines if you trust your campus dns server. The only other known alternative
> to me for such ssh fingerprint deployments is putting the keys into an LDAP
> server. Or put it on some web page, which is not very useful for automation.
>
> As for when you are on an untrusted network, an attacker would now have to
> both spoof your traffic to the DNS servers and man in the middle your ssh
> session. If you would use your own DNS, instead of a dhcp assigned one, the
> attacker would have to spoof more then just ssh. If you would be using a
> DNS server through a VPN, the attacker just can't spoof it at all.
>
> There is not question that SSHFP will become much more useful when combined
> with DNSSEC. But DNSSEC is already here and deployed. Some CC:TLD's deploy it.
> Many testbeds exist, and orgnaisations internally are using it.
>
> eg, an ssh session where VerifyHostDNS is enabled, would look like:
>
> [paul at bofh ]$ ssh paul at www.xelerance.com
> The authenticity of host 'www.xelerance.com (193.110.157.145)' can't be established.
> RSA key fingerprint is ae:e2:07:ed:6e:fe:d9:0a:fc:a1:36:b7:ed:62:35:13.
> Matching host key fingerprint found in DNS.
> Are you sure you want to continue connecting (yes/no)?
>
> It is still up to the human to make the decision. When a key would change,
> eg by a sysadmin or a hacker, you would get the additional LOUD warning
> about the "mismatching host key fingerprint found in DNS" which would
> clearly bring the point across that the ssh key changed and the admin didn't
> update the DNS, so therefor it is likely the admin didn't change the key,
> and your connection is being 'man in the middled'.
>
> To me, the important part is, we do not LOSE anything by enabling it. But we
> do facilitate early adopters of SSHFP and DNSSEC.
>
> Paul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>