Top Down Service Mapping Blocked by SSH Authentication Errors and Missing Load Balancer

[ChandanK0753855]

Hi Community,

I am currently working on a Service Mapping Top-Down implementation and have completed the initial readiness assessment. During this exercise, I identified a few challenges and would appreciate any guidance from those who have encountered similar issues.

 

Current Findings

1. Load Balancer Discovery

As part of the readiness check, I found that - 0 out of the 3 required load balancers have been successfully discovered.

2. Active Discovery Errors

There are several active Discovery errors in the environment. A significant number of them are related to SSH authentication failures: Could not find any valid credentials to authenticate the target for types [SSH Password, SSH Private Key, Azure SSH Certificate]

When investigating these errors, I noticed that many of the affected CIs:

• Were discovered through Qualys or Microsoft Intune integrations.
• Several CIs belong to classes such as: Hardware, DNS Name, IP Router, Other infrastructure-related classes. These would not typically be expected to support SSH access, yet Discovery appears to be attempting SSH connections on port 22.

3. So I focused on devices that I would expect to be accessible through SSH, like: F5 BIG-IP devices and Linux servers. These CIs appear to have been successfully discovered in the past by ServiceNow. However, current discovery attempts fail with the same SSH authentication error mentioned above.

To validate further, I attempted direct SSH connectivity from the MID Server and received the following error:

Unable to negotiate with host on port 22: no matching host key type found

This makes me wonder whether the issue is related to unsupported SSH algorithms between the MID Server's SSH client and the target devices rather than simply missing credentials.

4. Since Discovery remediation is currently incomplete, I attempted to create a few test Service Maps. However, I am encountering similar issues during the mapping process:

SSH authentication failed. Verify that credentials have been correctly defined for host.

Questions

I would appreciate advice on the following:

1. How can I identify and eliminate CIs that are not valid SSH candidates at the beginning of the Discovery remediation effort?
   • Many of the affected CIs appear to be classes such as Hardware, DNS Name, IP Router, or records sourced from Qualys and Intune.
   • What criteria should be used to determine whether a CI should qualify for SSH-based Discovery, so that time is not spent investigating devices where SSH is not expected or port 22 is not available?
2. Has anyone encountered a similar situation where Discovery attempts SSH authentication against CI types that would not normally support SSH connections?
   • If so, what typically causes this behavior, and how was it addressed?
3. Does the error below indicate an SSH algorithm or host key compatibility issue between the MID Server and the target device, rather than a credential issue? Unable to negotiate with host on port 22: no matching host key type found.
4. What are the recommended steps to troubleshoot and remediate SSH-related Discovery issues?
   • Are there best practices for validating connectivity, credentials, SSH versions, and supported host key algorithms before re-running Discovery?

At the moment, these issues are blocking further progress on the Service Mapping implementation, so any recommendations, troubleshooting steps, or lessons learned would be greatly appreciated.

Thank you in advance for your help.