Private key discoveries are failing

Technote (troubleshooting)


Problem(Abstract)

How to debug private key discoveries that are failing with access denied

Symptom

Session Sensor is receiving error during scan


Diagnosing the problem

Error seen on UI and session sensor:

CTJTP1160E The application cannot establish the following SSH session:
SessionClientException: CTJTP1190E The server did not complete the
authorization process..

Resolving the problem


In order to debug failure, please check the following:

Check the logs for the following entry:

example from this incidents- the TADDM environment was correctly configured and used the key:
2013-02-14 09:38:35,356 DiscoverManager [DiscoverWorker-3] SessionSensor-9.17.204.138-[23,22] DEBUG session.SshSession - Trying PKI SSH version=[2] host={addressType=4;stringNotation=9.17.204.138;}] user=[taddmcfm] keyfile=[/home/cmdbusr1/.ssh/id_rsa]
...
...
Later on in the log it showed the error which meant that is either using the wrong key or ssh is corrupted
2013-02-14 09:38:36,412 DiscoverManager [DiscoverWorker-3] SessionSensor-9.17.204.138-[23,22] WARN session.SshSessionClient - Command [cmd.exe /c echo AbstractSessionClient verifying session] failed in session ssh:/HostAuthcom.collation.platform.security.auth.HostAuth[taddmcfm][XXXXX]/null@9.17.204.138: SessionClientException: CTJTP1125E An error occurred when creating the SSH2 Session to taddmcfm@9.17.204.138: SSH2FatalException: Permission denied.

To resolve the issue, the right key was copied to the ssh id_rsa.pub file.

If the above is not the customer's issue and further debug needs to be conducted, turn on mindterm debugging

eg. set;

# Log file prefix for mindterm ssh2 debugging
com.collation.mindterm.Ssh2LogFilePrefix= /temp/ssh2
# Log level for mindterm ssh2 debugging (0=none, 7=all)
com.collation.mindterm.Ssh2LogLevel=7

Check the following and/ or run testssh.py

1. On the SSH server (ANCHOR)and the target, go to file
/etc/ssh/sshd_config - Enable SSH Tunnelling (Port Forwarding)
Change AllowTcpForwarding no to AllowTcpForwarding yes

2 ssh & scp must also be in the path of the user that start TADDM and
ANCHOR.

3 add the user/pw that starts TADDM and ANCHOR to the access list.

4. Test ssh communication from TADDM server to the ANCHOR using testssh.

5. On firewall and anchor ensure port 22 and 8497 to be open

6. From anchor test ssh communication to target using the taddm user
that runs the discovery ("ssh username@server uname").

If the discovery uses password authentication will it complete
successfully, but when discovery is using key authentication it fails?

7.Check what ssh configuration the environment is running?

8 Using a private key, double check the gateway( if one is in place). Ensure the id_rsa file is copied into the right path

example:
C:\cygwin\home\<user>\.ssh\id_rsa has the entry which is for the manual ssh connection. This
file is necessary and needs to also reside or copied over into C:\Documents and Settings\<user>\.ssh\id_rsa.

9. On the target check, for example on a UNIX target, the target would need the public
key in /home/cmdbusr1/.ssh/authorized_keys/id_rsa.pub

10. If ssh has gotten upgraded upgraded, you may need to check the following as well:
Newer versions of OpenSSH by default are compiled to use AES whenever the key is generated (rsa or dsa) and you have to convert the key using the following command:

openssl rsa -in id_rsa -out newkey_id_rsa -des3

Then copy the new_key_id_rsa file to the id_rsa file (the public key
doesn't change)

Product Alias/Synonym

TADDM

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Tivoli Application Dependency Discovery Manager

Software version:

Version Independent

Operating system(s):

AIX, Linux, Windows

Reference #:

1625584

Modified date:

2014-01-21

Translate my page

Machine Translation

Content navigation