Discovery of Linux servers with MACs and ciphers enabled for SSH connections

chodavarapu
Tera Contributor

Linux Engineering Team want to enable MACs and ciphers for all SSH connections to all Linux servers. We tried discovering one of the test servers with MACs and ciphers enabled. The discovery failed on SSH authentication. Please suggest on how we overcome this issue.

21 REPLIES 21

Thanks for your response. So you mean to say it is more related to credentials and not algorithm. Do I need to check with credentials?   client tried same credentials to login into target machine directly and was successful. Please assist with some more steps of troubleshooting here in.


Yes, the log you provided shows a successful connection where both sides were ready and willing to authenticate, but no credentials were tried.



Do you have any ssh credentials in the credential table?


Yes, I do have SSH credentials stored in Discovery credentials. These Credentials were tested by Linux team on target machine and succesfully logged in. Linux team is saying that MID server is not able to parse the connection due to algorithm. Below is XML of Unix classify Input ECC queue:



<results probe_time="8076" result_code="0"><result id="6f10ed420a0a0b7e49052d83a32b586f" name="sh ${file:esx.sh}" order="1" topic="SSHCommand"><results error="SSH authentication or connection failure" probe_time="2019" result_code="900000"><result error="SSH authentication or connection failure"><output/></result><parameters><parameter name="discover" value="CIs"/><parameter name="agent" value="mid.server.MID Server DEV2"/><parameter name="use_class" value="discovery_classy_unix"/><parameter name="source" value="172.22.1.22"/><parameter name="priority" value="0"/><parameter name="probe" value="10e0eebd0a0a0b4f61f46a5027df7fb6"/><parameter name="command_to_run" value="sh ${file:esx.sh}"/><parameter name="port_probe" value="97ff2abd0a0a070300b7f37daa11a241"/><parameter name="port" value="22"/><parameter name="cidata" value="&lt;CIData&gt;&lt;data&gt;&lt;fld name=&quot;ip_address&quot;&gt;172.22.1.22&lt;/fld&gt;&lt;/data&gt;&lt;/CIData&gt;"/><parameter name="used_by_discovery" value="true"/><parameter name="name" value="sh ${file:esx.sh}"/><parameter name="topic" value="SSHCommand"/><parameter name="esx.sh" value="#!/bin/sh&#13;&#10;# This command is rarely installed, so a Bourne shell script is used to squelch the exit status and sensor warning when not found.&#13;&#10;# tcsh doesn't squelch exist status codes within backticked statements&#13;&#10;echo `vmware -v 2&gt;&amp;1`"/><parameter name="ecc_queue" value=""/><parameter name="credential_id" value="528083ce4ffa0300b14e69118110c7b5"/></parameters></results></result><result id="e5e075a2a9fe1561018f2a9636d5ec39" name="uname -a" order="1" topic="SSHCommand"><results error="SSH authentication or connection failure: The connection did not complete" probe_time="2018" result_code="900000"><result error="SSH authentication or connection failure: The connection did not complete"><output/></result><parameters><parameter name="discover" value="CIs"/><parameter name="agent" value="mid.server.MID Server DEV2"/><parameter name="use_class" value="discovery_classy_unix"/><parameter name="source" value="172.22.1.22"/><parameter name="priority" value="0"/><parameter name="probe" value="10e0eebd0a0a0b4f61f46a5027df7fb6"/><parameter name="command_to_run" value="uname -a"/><parameter name="port_probe" value="97ff2abd0a0a070300b7f37daa11a241"/><parameter name="port" value="22"/><parameter name="cidata"


Bhanupratap Rathor wrote:



Yes, I do have SSH credentials stored in Discovery credentials. These Credentials were tested by Linux team on target machine and succesfully logged in.


Have you tried "test credentials" from the Discovery Credential record?


<results error="SSH authentication or connection failure" probe_time="2019" result_code="900000"><result error="SSH authentication or connection failure">


These lines would suggest the credentials could be at fault somehow - tests by the Linux team could be using something other than what you have stored.



Are you using keys?


Hi, Bhanupratap.



I can't reconcile the log you provided earlier with the error messages you are presenting now.



The earlier log you provided clearly shows negotiations advancing beyond kexinit, and they make use of DH group exchange, which is not supported in j2ssh.



The error messages you provide now show "SSH authentication or connection failure", an error message that only appears in j2ssh.



Perhaps the previous log was not a ServiceNow SSHCommand?



Please configure your mid server for sncssh by setting mid.ssh.use_snc = true and retry.



If it fails, recollect the logs as before.