Bug 20687

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

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.

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.

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?

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.

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.

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)

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)

Problem has gone away since I recompiled OpenSSH from the src.rpm to link it to 
the updated version of OpenSSL
(Thanks Nalin!)

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.

*** Bug 28870 has been marked as a duplicate of this bug. ***

*** Bug 26104 has been marked as a duplicate of this bug. ***

A more strict checking for the OpenSSL versions has been included in openssh-2.5.1p1.