Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 207725 - Review Request: sshfp - Generate SSHFP DNS records from knownhosts files or ssh-keyscan
Summary: Review Request: sshfp - Generate SSHFP DNS records from knownhosts files or s...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-22 18:27 UTC by Paul Wouters
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-09-30 19:29:48 UTC
Type: ---

Attachments (Terms of Use)

Description Paul Wouters 2006-09-22 18:27:34 UTC
Spec URL:
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 19:34:28 UTC
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 19:45:52 UTC
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 22:14:05 UTC
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 16:14:55 UTC
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

Comment 5 Jason Tibbitts 2006-09-26 18:27:37 UTC
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 18:52:37 UTC
That's corect. I found a bug in generating the sshfp records.

Spec URL:

* 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

Comment 7 Jason Tibbitts 2006-09-30 17:22:12 UTC
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 19:29:06 UTC
Thanks :)

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

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