Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: sshfp - Generate SSHFP DNS records from knownhosts files or ssh-keyscan https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207725 ------- Additional Comments From paul@xxxxxxxxxxxxx 2006-09-22 15:45 EST ------- It changes /etc/sshd/ssh_config not /etc/sshd/sshd_config. It only changes the behaviour of the ssh client. VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to “yes”, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to “ask”. If this option is set to “ask”, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be “yes”, “no” or “ask”. The default is “no”. Note that this option applies to protocol version 2 only. I do see your point about not installing this package everywhere, and as such enabling VerifyHostKeyDNS in the ssh client configuration is not very useful. I choose to enable it so that I can generate sshfp records on the same machine that I use to test the SSHFP records work properly. Do you still think it is a problem to enable this? The user will still be prompted for the new key, but an additional message appears saying the key matches the DNS entry for it. Extra big warning banners happen when you're being MITM'ed by someone redirecting your port 22 stream. I don't understand why RedHat does not enable VerifyHostKeyDNS. It only adds to security, at the expense of one DNS lookup. Especially with the first DNSSEC TLD's being in full production (amonst them all of RIPE-NCC's reverse!) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review