IV36031: THE WINSTLCF INSTALL THE ENDPOINT FAILED WITH SSH BY SHORT HOSTNAME
Closed as program error.
Problem Summary: tinti # /usr/Tivoli1/bin/aix4-r1/bin/winstlcf -j -d /usr/Tivoli/lcf -g tinti1.dk+9494 "meg01 root" Trying meg01... password for root: Could not determine INTERP for host meg01. Remote error: (null) (null) (null) (null) Standard Error: Host key verification failed. LCF Install failed for the following machines: (see lcfhost.err) meg01 Note: SSH access verification already working without any problems. Support engineer analysis: the problem we are facing is with ssh requiring to add new host keys to the $HOME/.ssh/known_hosts file. The first time ssh command is executed a new RSA key is created and added to know_hosts file together with the host name target of the command. Output looks like: [root@nc123041]/=> ssh -l root nc123041 "echo ALEX" The authenticity of host 'nc123041 (126.96.36.199)' can't be established. RSA key fingerprint is e6:db:da:e0:38:2e:e3:0c:38:18:6a:be:70:e9:26:95. Are you sure you want to continue connecting (yes/no)? I type yes, host become a "know_host" and next time command is executed without any question. In customer environment know_host file contains hosts meg01,188.8.131.52 If you manually run ssh -l root meg01 "echo Alex" or ssh -l root 184.108.40.206 "echo Alex" command is executed; but, if you run ssh -l root meg01.us.mach.com "echo Alex" command is not executed until customer type "Yes" In line 2007 of winstlcf hostname you pass to the script is converted to its full DNS name: ($g_host,$aliases,$type,$len,@that_addr) = gethostbyname($g_host); so, the command ssh is run against meg01.dk.mach.com and not meg01. meg01.us.mach.com is not in the know_host file and command is not executed. To avoid that I have added to the script the option StrictHostKeyChecking=no to automatically add the host and script should works. You can see the difference running: ssh -l root megs01.dk.mach.com "echo Alex" and ssh -o StrictHostKeyChecking=no -l root megs01.dk.mach.com "echo Alex"
The fix for this APAR is contained in or will be included in the following maintenance packages: Interim Fix 4.1.1-TMF-0132
Reported component name
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
Fixed component ID
Applicable component levels
Translate this page: