Discovery - SSH error when credentials authenticate successfully

Steph Slack
Kilo Contributor

Hi

We have implemented discovery and have an issue with discovering one set of Linux servers.

  • Access between the MID servers and Linux servers has been opened through the firewall
  • ports 22, 161 and 135 are open 
  • the credentials are in service now and authenticate successfully using the 'test credential' function
  • the correct IP ranges are in the discovery schedules 

But, when discovery runs we receive the following errors:

XXX is not a reachable host (no response to target ports scanned by MID or Target is blacklisted.  No valid credential found for types [SSH Password,SSH Private Key]

Any suggestions on other troubleshooting options?

2 REPLIES 2

tim_broberg
ServiceNow Employee
ServiceNow Employee

Hi, Steph.

So, clearly the mid (a mid?) has some connectivity or the Shazzam port scan on port 22 would have failed and we wouldn't even be trying ssh. Yeah, and the credential test.

  1. Can we assume that it's Unix - Classify that's failing? If not, then your server is getting offended after we start the conversation.
  2. First, look in the ecc_queue input. If authentication fails, there should be a credentials_debug section describing what he tried and any affinities or tags present.
  3. Try logging in with your standard open ssh or putty (or whatever) ssh client. Does it work?
  4. What if you do it from the mid server?
    (Yes, if test credential worked, almost certainly all this stuff worked, but it's cheap to check and expensive to asssume. At this point, I expect we have established that ssh works in general, and probably fails immediately in Unix - Classify during discovery. If not, It's probably time to stop and think about why.)
  5. Confirm that you're using sncssh. Look at your ecc_queue input record. It should include a parameter, use_snc_ssh = true.
  6. Enable debug logging on the client. Either set a parameter, debug = true, in your ecc_queue output and rerun it or set mid param mid.ssh.debug = true and rerun. Look for a great gush of debug information starting with "Using SNC" in the logs/agent0.log.0 file of your agent directory.
    (Then turn it off!)
  7. If the server is being fussy about something, turn on debug logging on the server. For openssh, this would usually be loglevel=debug in /etc/ssh/sshd_config and the output would be in /var/log/secure.

Hope this helps.

If not, we'll be here.
    - Tim.

Hi Tim

Yes, it is Unix classify that is failing and we can login with putty from the MID server. sncssh is enabled so I have enabled the debug logging and will see what that brings back after the next discovery scan on the weekend.

Thanks for your help so far

Steph