Bug 20687 - DSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
DSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 26104 28870 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-11 17:55 EST by David Woodhouse
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-24 03:13:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2000-11-11 17:55:42 EST
Is it just me, or is the above message from openssh _very_ _very_ scary?

As I live in the Free World and I mistakenly installed the US version of
RH7, I built my own openssl packages without 'hobble-openssl.sh' in the
build scripts. I also built my own openssh packages because of some
annoying bugs in the version shipped with RH7.

Today, I allowed up2date to update the openssh packages. However, upon
using it (with my own openssl package) I see the following:

DSA key fingerprint is 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00.
Are you sure you want to continue connecting (yes/no)? no

This frightens me. Lots. 

If we haven't already done so on the European CDs, can we have
fully-functional versions of openssl and openssh which are tested together
distributed to the Free World from ftp.redhat.de?
Comment 1 Nalin Dahyabhai 2000-11-20 16:19:35 EST
The algorithms which are disabled in the openssl packages are patented in many
parts of the world.  IDEA is also patented in Europe.  If the key's fingerprint
is coming up as a string of zeroes, then I'll need more information about which
versions of openssl and openssh you have built before I can even begin to try to
figure out what's going on.  Off-hand, I'd guess it's either a bug somewhere or
a really interesting key (because additive constants are used at every step in
the fingerprinting algorithms, it's possible that you'd get this from a good
key).
Comment 2 Brett S. 2000-11-27 01:09:23 EST
I receive the same message from ssh, while using the openssl-0.9.5a-1, openssh-2.1.1p4-1, and openssh-clients-2.1.1p4-1 packages from Red Hat. Likewise with the newer 2.3.0p1-4 version of the openssh and openssh-clients packages. I also obtain it from all of the several hosts which I have tried.
Comment 3 Brett S. 2000-11-27 12:19:37 EST
The bug might be resolved in Rawhide. After upgrading to openssl-0.9.5a-22 (with openssh and openssh-clients 2.3.0p1-4), more realistic-looking DSA keys appeared.
Comment 4 Nalin Dahyabhai 2000-11-28 17:14:44 EST
I'm still not exactly sure what would cause this, though, since I can't
reproduce it here.  Is this happening when connecting to localhost, or is the
server running a different server version?
Comment 5 David Woodhouse 2000-11-28 17:27:41 EST
shows up when connecting to localhost IIRC. Or possibly when connecting to the
afflicted machine from elsewhere.

I've given up and reinstalled the hobbled packages, but can rebuild and test
again if necessary.
Comment 6 Brett S. 2000-11-28 17:52:27 EST
As I said, I received it upon trying to connect to several remote hosts. They are all different architectures, running different operating systems and different versions of the ssh server. One is a Sparc running Debian GNU/Linux and OpenSSH 2.2.0p1. Another is an i586 running Red Hat GNU/Linux 6.0 and sshd from the ssh-server-1.2.27-5us RPM. The third is running HP-UX on an architecture I can't identify at the moment, running an older version of the sshd from the aforementioned RPM (compiled for HP-UX).

All three produced the same message described above, and none have this problem now that I have upgraded openssl.
Comment 7 Fran Boon 2001-02-05 11:00:51 EST
I get this too.
Client is RedHat 7.0, OpenSSH-2.3.0p1 (OpenSSL-0.9.6)
Server is RedHat 6.0 (Don't have SSH/SSL version numbers handy)
Comment 8 Fran Boon 2001-02-05 14:33:37 EST
Remote server (RH 6.0):
openssh-server-2.1.1p2-1
openssl-0.9.6-1

Reverse is fine - coming in from RH6 (2.1.1p2) to RH7 (2.3.0p1)
Comment 9 Fran Boon 2001-02-07 11:31:40 EST
Problem has gone away since I recompiled OpenSSH from the src.rpm to link it to 
the updated version of OpenSSL
(Thanks Nalin!)
Comment 10 Pekka Savola 2001-02-21 11:10:37 EST
This is caused by a mismatching OpenSSL / OpenSSH (the OpenSSL it was compiled against).

Most often I'd bet the user has installed OpenSSL 0.9.6 with RHL openssh or OpenSSH compiled against
OpenSSL 0.9.6 from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/rpm/.

You could be stricter in the spec file too; for example (like):

@@ -22,6 +22,8 @@
 # rpm -ba|--rebuild --define "rh7 1"
 %{?rh7:%define redhat7 1}
 
+%define exact_openssl_version   %(rpm -q openssl | cut -d - -f 2)
+
 Summary: OpenSSH free Secure Shell (SSH) implementation
 Name: openssh
 Version: %{oversion}
@@ -37,6 +39,7 @@
 BuildRoot: /tmp/openssh-%{version}-buildroot
 Obsoletes: ssh
 PreReq: openssl >= 0.9.5a
+PreReq: openssl = %{exact_openssl_version}
 Requires: openssl >= 0.9.5a
 Requires: rpm >= 3.0.5
 BuildPreReq: perl, openssl-devel, tcp_wrappers

Whether this is closed as NOTABUG or something else depends on the approach.
Comment 11 Pekka Savola 2001-02-23 10:33:27 EST
*** Bug 28870 has been marked as a duplicate of this bug. ***
Comment 12 Pekka Savola 2001-02-24 03:13:26 EST
*** Bug 26104 has been marked as a duplicate of this bug. ***
Comment 13 Pekka Savola 2001-03-03 19:53:30 EST
A more strict checking for the OpenSSL versions has been included in openssh-2.5.1p1.

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