Spec URL: ftp://ftp.xelerance.com/sshfp/sshfp.spec SRPM URL: ftp://ftp.xelerance.com/sshfp/sshfp-1.0.6-1.src.rpm Description: sshfp generates DNS SSHFP records from SSH public keys. sshfp can take public keys from a known_hosts file or from the host's sshd daemon. ssh can use these SSHFP records if you set "VerifyHostKeyDNS yes" in the file /etc/ssh/ssh_config. This package enables VerifyHostKeyDNS.
This package looks fine, but I would be extremely displeased if installing this package modified my sshd_config file. This is just a package that generates some DNS records; it has no business messing about with an unrelated part of the system. Besides, I wouldn't install this package on every SSH server; I'd instead run it on my name server which has a rather more restricted SSHd configuration that, frankly, nobody but me should ever touch.
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!)
My apologies; I misread the %post script. But still, I don't personally think it's appropriate for a package to mess with the config files of a mostly unrelated pacakge. Perhaps if the package installed some library necessary that enabled the ssh client to use this functionality, but even that is questionable. (Witness the problems with Spamassassin automatically enabling some functionality when certain Perl modules are installed. In that case there isn't even config file munging and there is still a general dislike of this kind of action at a distance.) Perhaps someone else will have a differing opinion. I don't really know why this isn't enabled by default; perhaps the additional DNS lookup is problematic.
Okay. I guess I agree this discussion should move to the openssh-clients package. * Mon Sep 25 2006 Paul Wouters <paul> - 1.0.6-2 - Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore
It looks like you're in the process of updating the package; the spec link in comment 1 shows version 1.1.0-1. Let me know when you have a new package ready.
That's corect. I found a bug in generating the sshfp records. Spec URL: ftp://ftp.xelerance.com/sshfp/sshfp.spec SRPM URL: ftp://ftp.xelerance.com/sshfp/sshfp-1.1.0-1.src.rpm * Tue Sep 26 2006 Paul Wouters <paul> - 1.1.0-1 - Mistakingly ran the sha1() call on the uuencoded keyblob, which generated wrong SSHFP records. * Mon Sep 25 2006 Paul Wouters <paul> - 1.0.6-2 - Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore * Tue Sep 19 2006 Paul Wouters <paul> - 1.0.6-1 - Initial release for Fedora Extras
Sorry for taking so long to respond. The only thing I have to say now is that you need to modify %description to match the current non-ssh_config-modifying behavior of the package. But you can do that when you check it in. Now I just need to figure out how to get my DNS configured to hand out these keys. * source files match upstream: 7bceb2240c34cb5929d931cd248e9e35 sshfp-1.1.0.tar.gz * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * dist tag is present. * build root is correct. * license field matches the actual license. * license is open source-compatible. License text included in package. * latest version is being packaged. * BuildRequires are proper (none) * %clean is present. * package builds in mock (development, x86_64). * package installs properly * rpmlint is silent. * final provides and requires are sane: sshfp = 1.1.0-1.fc6 = /usr/bin/python openssh-clients >= 4 python-dns * %check is not present; no test suite upstream. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * no scriptlets present. * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. APPROVED
Thanks :) Just concatenate the output of sshfp -a -s yourdomain.com to your zone file :)