Discovery - SSH error when credentials authenticate successfully
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2019 03:18 AM
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?
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2019 10:42 AM
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.
- Can we assume that it's Unix - Classify that's failing? If not, then your server is getting offended after we start the conversation.
- 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.
- Try logging in with your standard open ssh or putty (or whatever) ssh client. Does it work?
- 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.) - Confirm that you're using sncssh. Look at your ecc_queue input record. It should include a parameter, use_snc_ssh = true.
- 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!) - 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-30-2019 06:28 AM
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