I got a nexenta system,
I updated openssl to 1.0.1j, which I compiled from source code.
I updated openssh to 6.7, from source code as well, and I get this:

root@cteraportal:/root# openssl version
OpenSSL 1.0.1j 15 Oct 2014
root@cteraportal:/root# ssh -V
OpenSSH_6.7p1, OpenSSL 0.9.8k 25 Mar 2009

Should I expect the OpenSSL version to be updated on ssh?

  • Use PKG_CONFIG_PATH when you configure OpenSSH. Autotools will find the correct libraries and headers. LDFLAGS should also use -L/usr/local/lib/64 -m64 -Wl,-R,/usr/local/lib/64 to ensure the correct OpenSSL is used at runtime. For an example see GitHub | Build-Scripts.
    – user56041
    Jul 23, 2018 at 14:59

1 Answer 1


Why can't the OpenSSH configure script detect OpenSSL explains the possible cause that might have occured in your case.

Several reasons for problems with the automatic detection exist.

  • OpenSSH requires at least version 0.9.5a of the OpenSSL libraries.
  • Sometimes the distribution has installed an older version in the system locations that is detected instead of a new one installed.
  • The OpenSSL library might have been compiled for another CPU or another mode (32/64 bits). Permissions might be wrong.

The general answer is to check the config.log file generated when running the OpenSSH configure script. It should contain the detailed information on why the OpenSSL library was not detected or considered incompatible.

However, in your case I find this information as well.

Portable OpenSSH now requires openssl 0.9.8f or greater. Older
versions are no longer supported.

So as per your ssh -V command output, I think you are having a greater version than that is required.

  • Found the problem. Specifying "-m64" for compiler and linker fixed it.
    – csny
    Nov 3, 2014 at 17:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .