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  >

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

Authentication Service ,  

12 April,16 at 11:07 AM

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( 
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:/
To summarize
a) Centrify 2013, 2014 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.
A) 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 
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:

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.

Upgrade to Suite 2015 (5.2.2) or greater.