Run ssh command using the "allow_unsupported_shells" flag

Anders Westlund · ‎08-13-2019

Hi.

We are trying to get information from a Cisco device using ssh.

According to this documentation:
https://docs.servicenow.com/bundle/madrid-it-operations-management/page/product/discovery/reference/r_Parameters.html

I understand it as when using the "allow_unsupported_shells" flag no shell validation is done, and the command specified in the "ECC queue name" is run directly after ssh login. When I examine the logs (I have enabled the ssh_debug flag) it looks like the shell validation (i.e. the "echo $0" command) is run both with and without the "allow_unsupported_shells" flag.

Is it possible to avoid the "echo $0" when performing as ssh command via a probe, and move directly to the actual command and get it working according to documentation linked above?

I have enabled the "use_snc_ssh" flag (also validated that this is enabled by looking in the ssh logs) and we use MID server version:
madrid-12-18-2018__patch5-06-26-2019_07-01-2019_1425

Using the logs on the mid server I have also validated that the login is successful and that we get access to the device.

tim_broberg · ‎08-13-2019

From what I can see in the source, it should not be asking what the shell is when it doesn't care about the answer. It checks for unsupported shell && shell is not supported. If unsupported shell, then it should not progress to the other side of the && operator.

You're sure you have a parameter in the payload of the probe setting allow_unsupported_shells = true?

If this feature were to work, does it do what you need? I always struggled with it because the Cisco interface is so modal: enable mode, config mode, etc. It's hard to get anything done in one command. You may want to try patterns if not.

Sorry if this is unhelpful, but it is what I'm seeing. (Happily for me, there are no buttons for "mark unhelpful" or "reject as wrong solution".) 😉

- Tim.

Anders Westlund · ‎08-14-2019

Thanks for the reply:

We do not need to do enable etc, just a simple Cisco shell command.

I have tested both with and without the allow_unsupported_shells flag:

With allow_unsupported_shells

payload:

<?xml version="1.0" encoding="UTF-8"?>
<parameters>
   <parameter name="allow_unsupported_shells" value="true"/>
   <parameter name="credential_id" value="xxxxxxxxx"/>
   <parameter name="use_snc_ssh" value="true"/>
</parameters>

with name: show version

and I get this result:

<results error="Error; job finished with status ERROR: Problem in SSH session, job aborted: Session closed during channel open" post_processing_time="0" probe_time="1778" result_code="900000">
<result error="Error; job finished with status ERROR: Problem in SSH session, job aborted: Session closed during channel open">
<output>(Shell is not in supported shell list)</output>
</result>

I have also enabled SSH debug and inspected the log on the midserver, here is a part of the log (after the successful login)

DEBUG: [251/172.16.178.62:22] Received job message: JobStatusMsg OPENED Channel opened
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Client channel 1 is associated with server channel 3
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Processing ExecInitiateMsg
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Sending packet (before compression or encryption):
ByteBuffer: position(0), limit(25), capacity(25)
    0000:   62 00 00 00 03 00 00 00   04 65 78 65 63 01 00 00    b....... .exec...
    0010:   00 07 65 63 68 6f 20 24   30                         ..echo $ 0
As ASCII: b........exec.....echo $0
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Sending packet 8; 68 bytes: CHANNEL_REQUEST(3) type: exec, want reply: true, type-specific data: 11 bytes
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Set command timeout 150000 msecs com.snc.ssh.SSHTimer@6d5e3fe8
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Set timeout 120000 msecs com.snc.ssh.SSHTimer@77a97021
08/14/19 07:55:55 (752) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Channel state CHANNEL_OBTAINED-->EXEC_REQUESTED
08/14/19 07:55:55 (762) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Processing WrittenMsg, wrote 68 bytes
08/14/19 07:55:55 (812) SSHClientEngine DEBUG: [251/172.16.178.62:22] Enqueuing ReadMsg
08/14/19 07:55:55 (812) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Processing ReadMsg, read 36 bytes
08/14/19 07:55:55 (813) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Received frame:
ByteBuffer: position(0), limit(5), capacity(5)
    0000:   63 00 00 00 01    c....
As ASCII: c....
08/14/19 07:55:55 (813) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Processing: CHANNEL_SUCCESS(1)
08/14/19 07:55:55 (813) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Channel state EXEC_REQUESTED-->EXECUTING
08/14/19 07:55:55 (813) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Set timeout 120000 msecs com.snc.ssh.SSHTimer@560fa148
08/14/19 07:55:55 (933) SSHClientEngine DEBUG: [251/172.16.178.62:22] Enqueuing ReadMsg
08/14/19 07:55:55 (933) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Processing ReadMsg, read 420 bytes
08/14/19 07:55:55 (933) SSHProtocolEngine DEBUG: [251/172.16.178.62:22] Received frame:
ByteBuffer: position(0), limit(391), capacity(391)
    0000:   5e 00 00 00 01 00 00 01   7e 0d 0a 54 68 65 20 63    ^....... ~..The c
    0010:   6f 6d 6d 61 6e 64 20 79   6f 75 20 68 61 76 65 20    ommand y ou have
    0020:   65 6e 74 65 72 65 64 20   69 73 20 61 76 61 69 6c    entered is avail
    0030:   61 62 6c 65 20 69 6e 20   74 68 65 20 49 4f 53 2e    able in the IOS.
    0040:   73 68 2e 0d 0a 48 6f 77   65 76 65 72 2c 20 74 68    sh...How ever, th
    0050:   65 20 73 68 65 6c 6c 20   69 73 20 63 75 72 72 65    e shell is curre
    0060:   6e 74 6c 79 20 64 69 73   61 62 6c 65 64 2e 20 59    ntly dis abled. Y
    0070:   6f 75 20 63 61 6e 20 65   6e 61 62 6c 65 0d 0a 69    ou can e nable..i
    0080:   74 20 6f 6e 20 74 68 69   73 20 74 65 72 6d 69 6e    t on thi s termin
    0090:   61 6c 20 62 79 20 74 79   70 69 6e 67 0d 0a 20 20    al by ty ping..
    00a0:   20 27 74 65 72 6d 20 73   68 65 6c 6c 27 0d 0a 59     'term s hell'..Y
    00b0:   6f 75 20 63 61 6e 20 61   6c 73 6f 20 65 6e 61 62    ou can a lso enab
    00c0:   6c 65 20 69 74 20 66 6f   72 20 61 6c 6c 20 74 65    le it fo r all te
    00d0:   72 6d 69 6e 61 6c 73 20   62 79 20 63 6f 6e 66 69    rminals by confi
    00e0:   67 75 72 69 6e 67 20 74   68 65 0d 0a 20 20 20 27    guring t he..   '
    00f0:   73 68 65 6c 6c 20 70 72   6f 63 65 73 73 69 6e 67    shell pr ocessing
    0100:   20 66 75 6c 6c 27 0d 0a   63 6f 6d 6d 61 6e 64 2e     full'.. command.
    0110:   20 54 68 65 72 65 20 69   73 20 61 64 64 69 74 69     There i s additi
    0120:   6f 6e 61 6c 20 69 6e 66   6f 72 6d 61 74 69 6f 6e    onal inf ormation
    0130:   20 69 6e 20 74 68 65 20   6d 61 6e 20 63 6f 6d 6d     in the man comm
    0140:   61 6e 64 2e 0d 0a 46 6f   72 20 6d 6f 72 65 20 69    and...Fo r more i
    0150:   6e 66 6f 72 6d 61 74 69   6f 6e 2c 20 65 6e 61 62    nformati on, enab
    0160:   6c 65 20 73 68 65 6c 6c   2c 20 61 6e 64 20 74 68    le shell , and th
    0170:   65 6e 20 65 6e 74 65 72   3a 0d 0a 27 6d 61 6e 20    en enter :..'man
    0180:   49 4f 53 2e 73 68 27                                 IOS.sh'
As ASCII: ^.......~
The command you have entered is available in the IOS.sh.
However, the shell is currently disabled. You can enable
it on this terminal by typing
   'term shell'
You can also enable it for all terminals by configuring the
   'shell processing full'
command. There is additional information in the man command.
For more information, enable shell, and then enter:
'man IOS.sh'

Without allow_unsupported_shells

payload:
<?xml version="1.0" encoding="UTF-8"?>
<parameters>
<parameter name="credential_id" value="xxxxxxxxx"/>
<parameter name="use_snc_ssh" value="true"/>
</parameters>

with name: show version

I get another result:

So the flag obvious have some effect, but it looks to me as the echo $0 is still executed if the flag is set?

Anders Westlund · ‎08-23-2019

Is anyone running the "allow_unsupported_shells" flag and is able to run a ssh/shell command on for example a cisco device? We would be happy to hear how this was done, it might save us a lot of work.

ggarcia1 · ‎07-23-2020

Were you able to make any progress here? We're in a similar situation attempting to probe Cisco UCS/UCCX components.

We are able to login and CLI starts up, but then we get this:

<output>Command Line Interface is starting up, please wait ... (Shell is not in supported shell list)</output>