Diagnosing problems in SSH connections - syncsort_capacity_management - Latest

This section describes some techniques and options for diagnosing problems with an SSH connection from Control Center to a target system. It is not meant to be comprehensive.

1. Log on to the Control Center system as the Control Center Service Account. This is the account specified on the Log On tab of the Syncsort™ Capacity Management Control Center service properties dialog.
2. Open a command prompt on the Control Center system (remember it is only this one that communicates with target systems).
3. Issue a basic SSH command and request some diagnostic messages:

   ssh2 -d2 <user>@<address>

4. If you receive no messages at this point until some time later you receive a “time out” message, you can suspect basic network connectivity, as traffic is not getting from your Control Center system to the target and back. Ping and tracert commands to the target system may help to see where it is falling down, if you are allowed to do them. You might also have someone check the firewall rules to the target system to ensure they are passing traffic in both directions between the end points.
5. If you see a selection of messages confirming the versions of SSH that are attempting to converse, and the port number being used, then you can be sure that the low-level connectivity is in place (the pieces of wire) and that any routing and firewall rules are correctly set.
6. If you receive a prompt for a password or passphrase, check in System Manager that the Password authentication radio button is selected or Public Key authentication radio button is selected and Passphrase is entered. If it is not, then you need to determine with the security administrator for the target system whether or not you should be using password authentication (and what the password or passphrase might be!).
7. If you receive no prompt for a password, check in System Manager that the Public Key authentication radio button is selected and no passphrase is entered. If the target system is not expecting a password and Syncsort™ Capacity Management tries to force one upon it, it will stall the connection. You may need to check with the security administrator for the target system whether or not you should be using public key authentication.
8. Once you have entered the password, or your public key with or without passphrase has been accepted, you should be able to spot a message confirming Authentication successful. If not, examine the messages prior to this for a clue as to why this has not happened.
9. If you are disconnected after apparently being successfully authenticated, then there is likely to be some­thing wrong with the set up of the User ID on the target system. It could be that there are privilege problems so that the user does not have access to its home directory, or the account is disabled in some way.
10. If you are using the SSH Tectia Client and connections sometimes work and sometimes fail, this is possibly due to the password caching, a property that can be turned off by using the Configuration GUI. Go to Gen­eral->Defaults->Server and set a connection timeout value of zero.
11. If other problems occur, then setting a more verbose logging level in the sshd2_config file should help. You will have to restart the SSH server service or daemon to do this, having first set Loglevel INFO or Loglevel VERBOSE, DEBUG, DEBUG1 DEBUG2 or DEBUG3. Each option produces successively more messages. DEBUG3 will flood your target system with minute detail that will actually be very hard to wade through, so start with INFO, VERBOSE or DEBUG. For a Windows system this will generate application event log entries. For a UNIX or Linux system, messages are written to the system log.