SSH_Connection_Failure. Timed out while waiting for SSH protocol ID string

[mikefountain]

I have an SSH probe that logs into an F5 and issues a couple of 'list' type commands.

-- The SSH probe does have the "allow_unsupported_shells" set to True to deal with the F5 TMSH shell

When I test the probe against and F5, it runs just fine and gives me the data I'm expecting.

However, when I use the probe as part of discovery, it fails with the following error:

SSHCommand: Cannot connect, status is SSH_CONNECTION_FAILURE. Timed out while waiting for SSH protocol ID string:

For my discovery:

* I have SNMP port probe with a lower numbered classification priority than ssh (have SNMP as 2, SSH as 3)

* It classifies properly as an F5 and the SNMP probes all run properly

* It starts the SSH probe, and after the couple minute timeout the ssh probe fails with that error

Any idea why the SSH connection would work probably when I test the probe manually, but fail with that error when it is launched as part of disocvery?

[Marlos]

Hi Mike, have you attempted to connect via SSH Private Key Credentials? You could also try to SSH from the MID Server or test the SSH port to F5 from there in case you have any ACL/Firewall blocking that traffic from the MID server to F5.

[angeliccharm]

Hey Mike,

One thing that potentially could be causing an issue is if you're using an External Credential Store for your credentials. If so, it may not be reading the ID correctly for Discovery.

Coming to Knowledge17? Stop by to say "Hi" and we can discuss further too; we'll be at booth # N19.

[Suzi Dowhie]

Hi Mike,

We went through multiple troubleshooting steps to remedy the same error after our Helsinki upgrade.

Modification to the MID server settings included mid.connection_cache set to 'false'. Once we added this parameter and re-started the MID server, the connectivity failures stopped. We also found modification of the following parameters were useful in tailoring the MID server to our environment:

• mid.ssh.channel_timeout
• mid.ssh.command_timeout_ms
• mid.ssh.socket_timeout
• mid.ssh.use_snc
• mid.ssh.connections_per_host
• threads.max

The default value of 120000 for the timeouts equates to 2 minutes in real time and ours required adjustment to the maximum 600000, or 5 minutes, to account for the JVM structure in place. The threads.max value allows for more probes and sensor executions to be run in the 5 minute interval. As such, Discovery scans, reports and the like are completing without issue.

I hope it helps!

Suzi