Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-4233: unable to scp/ssh LIBPATH is set

Centrify DirectControl ,  

12 April,16 at 11:07 AM

Applies to:
 
Centrify-enabled OpenSSH bundled with Suite 2013 or higher on AIX systems
 
Question:
 
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 
/libkrb5support.a(shr.o.0.0) because: 
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. 
lost connection 
 
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
 in:/usr/vacpp/bin:/app/oracle/product/11.2/ora11g/bin:$PCODIR/bin:/opt/IBM/ldap/ V6.2/sbin:/opt/IBM/ldap/V6.2/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/
sbin:usr/local/bin:/usr/local/bin/:/usr/local/SMI/Bin:/usr/local/sbin:/usr/opt/ifor/ls/os/aix/bin:/opt/LicenseUseManagement/bin" 
 
To summarize
 
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.
 
Answer:
 
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)
 
Workaround:
 
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/lib64
/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:

http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.pli.doc%2Fibmx2mst21.htm

Update (7/24/2014)

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
fix.

 

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.