Cannot connect, status is TCP_CONNECTION_DROPPED. Connection unexpectedly closed by SSH server:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
In Prod, we tried to discover the solaris server & getting this below error
Cannot connect, status is TCP_CONNECTION_DROPPED. Connection unexpectedly closed by SSH server:
In UAT, the same server got discovered using different mid server.
Kindly help to remediate this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @mahadevan3562
Here are couple of community posts related to the same issue:
https://www.servicenow.com/community/itom-forum/sshcommand-cannot-connect-status-is-tcp-connection-d...
https://www.servicenow.com/community/itom-articles/tcp-connection-dropped-connection-unexpectedly-cl...
https://www.servicenow.com/community/itom-forum/cannot-connect-status-is-tcp-connection-dropped-conn...
https://www.servicenow.com/community/itom-forum/discovery-tcp-connection-dropped-error/m-p/2386364
Hope that helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago - last edited 2 weeks ago
Hi @mahadevan3562 follow these steps
1. Network Access (Firewalls)
Before the MID Server can even try to log in, it needs to reach the target IP on the specific port required (e.g., Port 22 for SSH/Linux or Port 135/445/5985 for WMI/WinRM/Windows).
-
The Check: Verify if there is a firewall, Access Control List (ACL), or Intrusion Prevention System (IPS) between the MID Server and the target.
-
Why it fails: If the connection is dropped immediately, it often means the firewall is silently discarding the packets or the target host isn't allowing the MID Server's IP address.
2. Review Credentials & Test Them
Even if the port is open, the "Dropped" error can occur if the target server rejects the handshake because of account issues.
-
The Check: Go to Discovery > Credentials in ServiceNow. Find the credential being used and use the "Test Credential" button.
-
Common Culprit: the account might be expired or locked on the target server. A server will often drop a connection if the PAM (Pluggable Authentication Module) rejects the user before the session fully opens.
3. Update Discovery/Service Mapping Patterns
Patterns are the "instructions" ServiceNow uses to find details about a CI once it logs in.
-
The Check: Ensure your Discovery and Service Mapping Patterns store app is up to date via the ServiceNow Store.
-
Why it matters: Occasionally, a bug in an older pattern can cause a command to be sent that the target server views as "malicious" or "malformed," leading the server to terminate the connection abruptly.
4. Check Agent.log & Wrapper.log
These logs live on the physical or virtual server where the MID Server software is installed, not inside the ServiceNow web interface.
-
The Check: Navigate to the
/agent/logs/folder on your MID Server host.-
Agent.log: Shows the specific Discovery probes/patterns being sent and the raw error returned by the OS.
-
Wrapper.log: Useful if the MID Server itself is crashing or running out of memory while trying to handle the connection.
-
-
Pro Tip: Look for "SSHException" or "Connection reset" timestamps that match your Discovery schedule.
5. Debug the Pattern Itself
If the connection drops after Discovery has already started (during the Identification or Exploration phase), the issue is likely a specific step in the pattern.
-
The Check: Use the Pattern Designer. Open the pattern in "Debug" mode, enter the IP of the failing CI, and run it step-by-step.
-
Goal: Find exactly which command causes the connection to drop. Some high-security servers will kill a session if a user (the MID Server) tries to run a restricted command like
sudoornetstat.
