SSHCommand: Cannot connect, status is TCP_CONNECTION_DROPPED - Support and Troubleshooting

SSHCommand: Cannot connect, status is TCP_CONNECTION_DROPPED Issue  SSHCommand: Cannot connect, status is TCP_CONNECTION_DROPPED

Release All releases - MID Server Discovering a Linux system

Cause Service rejected connection due to several reasons as described next.

Resolution Attempt to reproduce the same conditions with a third-party ssh client such as openssh or putty from the MID server and confirm if it's successful.

Inspect the security logs on the server to see if you can find any specific error: /var/log/secure Increase debugging on the server. For openssh, this typically means editing /etc/ssh/sshd_config, setting loglevel=debug3, and restarting sshd. Recreate the failure, then inspect the logs on the server /var/log/secure With openssh, run ssh with the "-vv" option to connect to the server. Look at the kexinit messages to see if they're abnormal in terms of supported algorithms. Turn on ssh debug from the sncssh ServiceNow ssh client by setting the mid parameter mid.ssh.debug = true , then reproduce the issue again. The agent/logs/agent0.log.* logs will have lots of debug info which will start with "Using SNC". This will be a whole lot of information, and will more than likely just show that they hung up on us for no obvious reason, but when they hung up may be instructive: If they hung up after kexinit but before userauth that would indicate that the algorithm negotiations did not go well. Look at the kexinit messages and compare the list of algorithms for each thing, trying to find where the server's list has no items on the client's list. If we get all the way to userauth, are the credentials tried the ones you expected? When did it give up?