Comment 6 for bug 708493

Sooo, I found this. All the failing systems have

ii libssl1.0.0 1.0.0c-2 SSL shared libraries

installed (I compiled Postfix against openssl-1.0.0, that's why it's installed), yet their sshd is not linked against libssl1.0.0:

mail:~# ldd /usr/sbin/sshd
 linux-gate.so.1 => (0xb774f000)
 libwrap.so.0 => /lib/libwrap.so.0 (0xb76c2000)
 libpam.so.0 => /lib/libpam.so.0 (0xb76b6000)
 libselinux.so.1 => /lib/libselinux.so.1 (0xb769a000)
 libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7542000)
 libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb753e000)
 libz.so.1 => /usr/lib/libz.so.1 (0xb752a000)
 libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb74f8000)
 libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb74c8000)
 libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7416000)
 libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7413000)
 libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb72cd000)
 libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb72b6000)
 libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb72b1000)
 /lib/ld-linux.so.2 (0xb7750000)
 libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb728e000)
 libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7287000)
 libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb7284000)
 libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7270000)
 libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7256000)

The verbose output indicates this immediately before failure:

...
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Read from socket failed: Connection reset by peer

ECDH being elliptical curve diffie hellman -- but one needs openssl-1.0.0 (or at least 0.9.9) for that.
Since sshd is not linked against 1.0.0, it cannot handle ECC (elliptical curve cryptography) at all.

But the real question is: Why is ECC being used if ONE of the two sides doesn't support it?!