SSHCommand: Cannot connect, status is TCP_CONNECTION_DROPPED. Connection unexpectedly closed by SSH server:

justx · ‎05-29-2018

Hello community,

Could you please help me understand the following warning/error message:

SSHCommand: Cannot connect, status is TCP_CONNECTION_DROPPED. Connection unexpectedly closed by SSH server:

It shows this one when I am trying to test the credentials of one target host and in discovery logs.

What it means, how to fix it or what to troubleshoot ?

tim_broberg · ‎05-29-2018

It means the server hung up on us, for whatever reason.

Often, it means we've tried too many credentials and triggered a security alert, but you're saying you're testing a single credential, so that seems unlikely. It might mean that the set of algorithms the client offers are unacceptable to the server.

Debug options:

Try to reproduce the same conditions with a standard ssh client like openssh or putty and see if it works. Let's establish that the server works at all.
Try #1 again from the mid server itself in case the server has something against that host. It's unlikely, but it's easy to rule out.
Squint at the security logs on the server to see if you can find any specific complaint. /var/log/secure often has good info.
Crank up the debug on the server. For openssh, this typically means editing /etc/ssh/sshd_config, setting loglevel=debug3, and restarting sshd. Recreate the failure, then weed through the logs (/var/log/secure?), and you should see exactly what offended the server.
With openssh, run ssh with the "-vv" option to connect to the server. Look at the kexinit messages to see if they're especially exotic. (A typical sncssh kexinit message showing the supported algorithms is at bottom.)
You can get debug info from the sncssh servicenow ssh client by setting the mid parameter mid.ssh.debug = true (or, if things are busy, to the IP address of the target to keep the amount of debug traffic manageable), then try again to connect. 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:
a) If they hung up after kexinit but before userauth that would indicate that the algorithm negotiations did not go well. Squint 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.
b) If we get all the way to userauth, are the credentials tried the ones you expected? When did it give up?

I've debugged dozens of these, and that's my usual bag of tricks.

Good luck, and it would be great to hear what you try and what works or doesn't.

- Tim.

Here's a typical sncssh kexinit message. You might have trouble, for example, if the server did not support any aes or 3des cipher algorithms.

07/28/17 00:19:56 (008) SSHProtocolEngine DEBUG: [2520/10.11.12.13:22] Sending packet 0; 544 bytes: Client KEXINIT:

Cookie: 6cad40010640976136179e2cf0ab42ee

Key Exchange Algorithms: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha256, diffie-hellman-group1-sha1

Signature Algorithms: ssh-dss, ssh-rsa

Client-to-Server Cipher Algorithms: aes128-ctr, aes192-ctr, aes256-ctr, 3des-ctr, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc, none

Client-to-Server MAC Algorithms: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, hmac-md5, hmac-md5-96

Client-to-Server Compression Algorithms: none

Server-to-Client Cipher Algorithms: aes128-ctr, aes192-ctr, aes256-ctr, 3des-ctr, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc, none

Server-to-Client MAC Algorithms: hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, hmac-md5, hmac-md5-96

Server-to-Client Compression Algorithms: none

First packet follows: false

View solution in original post

bhanupratap2203 · ‎02-14-2019

Hi Tim,

How about the Quick discovery worked fine but during the schedule discovery i got the same error for that particular server. Any explanation behind this.

Girija Sankar G · ‎01-11-2023

@tim_broberg , am getting same error and checked the debug logs.

Any solution around this issue?

In my cases:-

Target server is reachable

Port 22 is open

doing SSH using putty and unable to login to target server, its showing "remote side unexpectedly closed network connection"

Tried discovery after turning on Debug, looks like same error as you got.

reich · ‎05-29-2018

as tim suggested. it means that you are using the wrong credentials. are you sure you have access to it and does it allow ssh? usually a port needs to be in i think its default by port 22 if im not mistaken.