No shell detected and probe parameter 'allow_unsupported_shells' is set to 'false'

[BK14]

Good day experts,

When discovering some Linux servers in DMZ, I get these "warning" msgs:

• Exit status: 1 WARNING: Your password has expired. Password change required but no TTY available.
• No shell detected and probe parameter 'allow_unsupported_shells' is set to 'false'
• Request not sent to uri= https://"IP ADDRESS"/api/cluster : java.net.SocketException: Socket is closed

We use the local account to authenticate these servers.

I tested credential in the "Discovery | Credentials" module and it passes with the local account. Why am I still getting the password expired msg? Is this the actual issue? or the next warning about the unsupported shell is causing the failure?

Thank you all

bk

[Community Alums]

Hi @BK ,

Refer to this support KB to get rid of "No shell detected and probe parameter 'allow_unsupported_shells' is set to 'false'" : https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0855650

Looks like something wrong between your servicenow and MID server connection for your third error.

Mark my answer correct & Helpful, if Applicable.

Thanks,

Sandeep

[BK14]

Hi Sandeep, I read the doc you sent and was not sure about the first step.

• Execute "Test input" on the target device, from the custom activity and observe the output like below.

not sure where this should be tested. What is "Test input" and how to test, etc? I assume I have to run targeted discovery on one server IP.

I activated the SSHCommand Probe to be used by discovery, then added the "allow_unsupported_shells parameter to the Probe Parameters and it didn't work.

I then added the "mid.ssh.shells_supported" parameter to the MID server parameters as well as adding "allow_unsupported_shells" to the MID Server | Properties.

None of these work. I think I should open a HI for this. 

Thank you

bk

[Community Alums]

Hi,

Test input here means to run discovery on IP.

Yes..you can raise a support ticket by the mean time.

[tim_broberg]

The shell business is about SSHCommand running echo $0 to detect what the shell is. If he can't make any sense of the answer, he's uncertain how to address the server.

allow_unsupported_shells bypasses the check, but then SSHCommand doesn't know how to call shell scripts or set paths, so it is very limited in what it can do.

Check /etc/passwd for the account your using to see what the shell is and consider moving to one of the supported ones, sh, bash, csh, etc.