6

I am getting no version information available when making ssh.

Openssl verion:

sat:~# openssl version
OpenSSL 1.0.1f 6 Jan 2014

Here is output of ldd /usr/bin/ssh:

/usr/bin/ssh: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/ssh)
    linux-vdso.so.1 =>  (0x00007fff48bff000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fdd57f1f000)
    libcrypto.so.1.0.0 => /usr/local/lib/libcrypto.so.1.0.0 (0x00007fdd57b3a000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdd57935000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdd5771e000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fdd57508000)
    libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fdd572c8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd56f3e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fdd583b3000)
    libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fdd56c6a000)
    libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fdd56a40000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fdd5683c000)
    libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fdd56633000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fdd5642e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd56212000)

Output of locate libcrypto.so.1.0.0:

sat:~# locate libcrypto.so.1.0.0
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/local/lib/libcrypto.so.1.0.0
/usr/src/openssl-1.0.1f/libcrypto.so.1.0.0

How to fix this error?

Note:

I compiled and installed the openssl. After that, I installed ssh through apt-get.

Improve this question
2

4 Answers 4

Reset to default
4

I compiled and installed the openssl. After that, I installed ssh through apt-get.

These are probably two different versions of OpenSSL. You will probably be OK since 1.0.0 is binary compatible with 1.0.1, 1.0.2, etc (it won't be binary compatible with 1.1.0, however).

Your ssh is probably using the version of OpenSSL in /usr/lib/x86_64-linux-gnu/. You should use LD_PRELOAD to ensure your version of OpenSSL is being used (assuming binary compatibility, of course).

If you don't want to use LD_PRELOAD and friends, then build ssh from sources. Be sure to specify an rpath to ensure the link editor uses your version of OpenSSL, not he system's version. That is, your LDFLAGS should include something like -Wl,-rpath,<path to your openssl>. That's in addition to the customary -lcrypto, -lssl and -L<path to your openssl>.

If you are on Mac OS X, then be advised that linker options like -Bstatic and -rpath are silently ignored. You will encounter mysterious crashes due to incompatible binaries because OS X provide 0.9.8.

no version information available

As for no version information, I have no idea. ssh can use either OPENSSL_VERSION_NUMBER at compile time or SSLeay/SSLeay_version at runtime. See OPENSSL_VERSION_NUMBER(3) for details.

How to fix this error?

Perhaps I'm misreading things, but I don't see an error anywhere in the post.

Improve this answer
9

Problem: libssl.so.1.0.0 and libcrypto.so.1.0.0 no version information available warning/error.

After much research, time and effort, (took weeks), here's what I finally ended up doing...

In the directory where you ended up extracting the source code for your version of openssl 1.0.1h (should work for other versions too.) I create a file called openssl.ld

In this file put this...

OPENSSL_1.0.0 {
    global:
    *;
};

save it. Now type in...

make clean

(Just to be sure we are starting fresh.)

Now for the really mind boggling part...

./config --prefix=/usr/local --openssldir=/usr/local/openssl shared -Wl,--version-script=openssl.ld -Wl,-Bsymbolic-functions

Then...

make
make test
make install
ldconfig

And that should do it. (It's so simple. No patching required.)

I have applied this solution to Debian Wheezy both 32 and 64 bit versions. And have made an observation. The 64 bit version automatically defaults to the new libssl.so.1.0.0 and libcrypto.so.1.0.0 files that are created in the /usr/local/lib directory. The 32 bit version does not. Which is why I had thought at first that the 32 bit version of Debian Wheezy didn't suffer from this problem, but it does once you get the 32 bit version to use the new openssl libraries in the /usr/local/lib dir.

Using the ldd command to test what libraries the binaries are using was invaluable in figuring this out too.

Improve this answer
1
0

I have just discovered that my above solution breaks certain binaries that require an OPENSSL_1.0.1 version. Like curl for example. apt-file search will no longer work with my solution as that uses curl. So some binaries want a 1.0.0 version and others want a 1.0.1 version.

I believe the solution lies in a editing of the openssl.ld file. So that some binaries will get the 1.0.0 version and other will get a 1.0.1 version. At the moment this is beyond me. Maybe somebody else can solve this.

Improve this answer
0

If you want to install custom-compiled libraries, don't break your system by installing to prefixes /usr/local, /usr or /. Debian/Ubuntu, for example, will pick up custom libraries in /usr/local/lib the next time ldconfig is invoked because it's usually listed in /etc/ld.so.conf.d/libc.conf.

Here's a throw-away box with openssl 1.0.2e make install'ed to --prefix=/usr/local and then run ldconfig (with no arguments, which updates /etc/ld.so.cache):

# ldconfig -p | egrep 'lib(crypt|ssl)'
libssl.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libssl.so.1.0.0
libssl.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl.so (libc6,x86-64) => /usr/local/lib/libssl.so
libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/local/lib/libcrypto.so.1.0.0
libcrypto.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so (libc6,x86-64) => /usr/local/lib/libcrypto.so
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
libcrypt.so.1 (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/libcrypt.so.1
libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.24) => /lib/x86_64-linux-gnu/libcrypt.so.1
libcrypt.so.1 (libc6, OS ABI: Linux 2.6.24) => /lib32/libcrypt.so.1
libcrypt.so (libc6,x32, OS ABI: Linux 3.4.0) => /usr/libx32/libcrypt.so
libcrypt.so (libc6,x86-64, OS ABI: Linux 2.6.24) => /usr/lib/x86_64-linux-gnu/libcrypt.so
libcrypt.so (libc6, OS ABI: Linux 2.6.24) => /usr/lib32/libcrypt.so

Notice how the custom-compiled ones override libs from the openssl package.

Instead, the solution is to vendor custom libraries and binaries into isolated directories that are independent from the default ld.conf and PATH.

Install software to /opt/$WHATEVER-$VERSION/

Then, if you want to use custom-compiled binaries in /opt/$WHATEVER-$VERSION/bin, append that to the PATH (DO NOT PREPEND, because of the risk of breaking the system).

For static linking $WHATEVER to something else

export CFLAGS="$CFLAGS -I/opt/$WHATEVER-$VERSION/include" \
   CXXFLAGS="$CXXFLAGS -I/opt/$WHATEVER-$VERSION/include" \
   LDFLAGS="-lwhatever -L/opt/$WHATEVER-$VERSION/lib"

For shared linking $WHATEVER to something else

Same as above but add -Wl,-rpath,/opt/$WHATEVER-$VERSION/lib to LDFLAGS

Another thing to do is instead of make install use checkinstall to build a removable package where the full package name includes custom-$WHATEVER-$VERSION to allow easier version management to avoid breaking custom packages through incompatible upgrades.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.