Linux

Hello,

I'm facing an issue after upgrading CFT (File transfer tool) from 2.5 to 2.7, on one of our test Linux boxes.

With CFT profile loaded, we can not initiate remote connections (ssh user @ server). We have the following message:

OpenSSL version mismatch. Built against 90801f, You have 908,060

Without the loaded profile, we can connect with the same command, but CFT specific commands fail.
CFTUTIL: error while loading shared libraries: libcfttools.so: can not open shared object file: No such file or directory
cftutil error code 127

Could you please suggest as to what can be done??

Additional information:

openssl version
OpenSSL 0.9.8a 11 Oct 2005

With CFT profile loaded:
openssl version
OpenSSL 0.9.8a 11 Oct 2005 (Library: OpenSSL FIPS Object Module v1.2)

Could you please tell me how to disable fips? or any other advice.


Regards,

did you reinstall all the openssh tools?

[SOLVED] Starting sshd: OpenSSL version mismatch. Built against 10000003, you have 90802f

Hello,

Thank you for your reply.

I really cant upgrade or patch OpenSSH as our servers are provisioned by a software provider. In case we upgrade, their support on this server will end.

Libraries shipped with the product CFT incorporated openSSL entries, are at a different level than what is installed on the system.

I see that in CFT_HOME/lib, there is library called libcrypto.so.0.9.8; if I discard this lib, both CFT cmd and SSH function together.

Could you suggest if removing libcrypto could be a good workaround?

Regards,

You can try to get/make a version of CFT that works with old SSH libs. Sometimes it is easy, if no function prototypes change and the list of object names linked is still supported.

You can ask your software provider to do a maintenance release and get their ssh up to date (seems insecure not to!). Be careful they do not go farther, if there is a farther.

You can write a pair of apps to fake the library, where one seems to be the desired, mising library but is a C++ wrapper and the other links to the ssh lib you have. When the fake libssh.x gets a call, it sends it to the second piece linked to libssh.x-1, which makes the call, and sends the response back so the first can return it. If the first changes directory, it needs to detect that so the other can follow, else file names in arguments will not work. If there is any other activity that is very local, like passing open fd, that would be a problem. Data could be in an mmap'd file space so pointers can be passed, but pointers in to any call mean the object pointed to needs copying back and forth. If you are lucky, you only need a few calls to make it happy.