Bug 207725 - Review Request: sshfp - Generate SSHFP DNS records from knownhosts files or ssh-keyscan
Review Request: sshfp - Generate SSHFP DNS records from knownhosts files or s...
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-09-22 14:27 EDT by Paul Wouters
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-30 15:29:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Wouters 2006-09-22 14:27:34 EDT
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.
Comment 1 Jason Tibbitts 2006-09-22 15:34:28 EDT
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.
Comment 2 Paul Wouters 2006-09-22 15:45:52 EDT
It changes /etc/sshd/ssh_config not /etc/sshd/sshd_config. It only changes the
behaviour of the ssh client. 

             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

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!)

Comment 3 Jason Tibbitts 2006-09-22 18:14:05 EDT
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.
Comment 4 Paul Wouters 2006-09-25 12:14:55 EDT
Okay. I guess I agree this discussion should move to the openssh-clients package.

* Mon Sep 25 2006 Paul Wouters <paul@xelerance.com> - 1.0.6-2
- Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore
Comment 5 Jason Tibbitts 2006-09-26 14:27:37 EDT
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.
Comment 6 Paul Wouters 2006-09-26 14:52:37 EDT
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@xelerance.com> - 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@xelerance.com> - 1.0.6-2
- Don't change VerifyHostKeyDNS in /etc/ssh/ssh_config anymore

* Tue Sep 19 2006 Paul Wouters <paul@xelerance.com> - 1.0.6-1
- Initial release for Fedora Extras
Comment 7 Jason Tibbitts 2006-09-30 13:22:12 EDT
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
   openssh-clients >= 4
* %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.

Comment 8 Paul Wouters 2006-09-30 15:29:06 EDT
Thanks :)

Just concatenate the output of sshfp -a -s yourdomain.com to your zone file :)

Note You need to log in before you can comment on or make changes to this bug.