Centrify-enabled OpenSSH bundled with Suite 2013 or higher on AIX systems
The command scp or ssh fails after installing Centrify OpenSSH with the following error
This was narrowed to LIBPATH used by Lawson application (Note: its not a Centrify product)
$ scp gen.count user@localhost:/tmp/user
exec(): 0509-036 Cannot load program /usr/share/centrifydc/bin/ssh because of the following errors:
0509-130 Symbol resolution failed for /usr/share/centrifydc/kerberos/lib
0509-136 Symbol memcpy (number 16) is not exported from
dependent module /lib/libcrypto.a(libcrypto.so.0.9.8).
0509-026 System error: Error 0
0509-192 Examine .loader section symbols with the
'dump -Tv' command.
PATH "/usr/local/SMI/Perl64:/app/lawson8/gen/cgi-bin: /app/lawson8/gen/bin:/usr/java6_64/bin:/app/cobol/bin:/usr/bin/perl64:/usr/vac/b
a) Centrify 2013 does not work if LIBPATH is set.
b) Centrify Version 2012 works perfectly no matter if LIBPATH is set or not.
c) Changing LIBPATH on a lot of jobs is manual and could cause other job to fail if LIBPATH is set.
When Centrify Suite 2013 or higher is installed, it also brings the crypto library.
Normally we use the existing OS crypto library but in some environment it may have an older version or a conflict.
LIBPATH limits which library to look at. It never tries to look at Centrify library located in /usr/share/centrifydc/lib/lybcrpto*,
so adclient tries to use what the OS has and scp fails for /usr/share/centrifydc/kerberos/lib/libkrb5support.a(shr.o.0.0)
From Suite 2013 onwards, Centrify changed the behavior as its now dynamically linked. The same shared library is used by various components.
It cannot be statically linked (many other bugs had to be fixed)
A) If customer is willing to change the LIBPATH for scp to work with Centrify OpenSSH
Set the LIBPATH to add these in front of /usr/lib:
/usr/share/centrifydc/lib path to your LIBPATH before the /usr/lib
so that Centrify library will be called ahead.
# export LIBPATH=/usr/share/centrifydc/lib:$LIBPATH
# export LIBPATH=/usr/share/centrifydc/lib64:$LIBPATH
# echo $LIBPATH to verify
Also verify by running:
#lslpp -f CentrifyDC.core |grep -i crypto
Note: If there are quite a few servers and batch jobs where LIBPATH need to be changed manually, customers can contact support for
a possible script.
B) This issue does not happen with stock OpenSSH and so if customers do not need Kerberos/SSO functionality, they can proceed to
uninstall Centrify OpenSSH and use stock SSH instead.
Additional reading provided as a courtesy:
1) The issue is the OpenSSL libcrypto library that CentrifyDC ships is built emitting a symbol for function memcpy() while the one from
OS vendor (like AIX) does not.
2) Normally, the dynamic loaders figures this out by looking at the executable/library header.
3) The problem is that this can be overridden by such directive as LIBPATH on AIX or LD_LIBRARY_PATH.
so, now the dynamic loader picks the library based on this specification, and as a result failed to find the memcpy function from the OS libcrypto.
4) Technically, this issue is caused by the override of library load order.
5) Centrify will look into providing fix to this in a special build off Centrify DirectControl 5.1.2 branch. The upcoming release of 2014.1 will not have this