Why is ExtremeXOS ssh exit status 255 when no error occurs?

  • 0
  • 3
  • Question
  • Updated 2 years ago
  • Answered

I'm trying to create some scripts to execute commands on Summit boxes using SSH but, even though the commands execute correctly, I always get 255 (-1) as the exit code. From OpenSSH man page I saw that 255 is expected to indicate errors like a connection failure, which clearly is not the case. Isn't EXOS supposed to return 0 when everything works correctly?


#> ssh user1@summitBox "show version | include Extreme"
Keyboard-interactive authentication
Enter password for user1:
Image   : ExtremeXOS version by release-manager

#> echo $?
Am I doing something wrong?

From ssh man page:

    ssh exits with the exit status of the remote command or with 255 if an error occurred.

The problem with this behavior is that it breaks any automation script that expects a value between 0 and 254 as the return code when no error occurs with the ssh client itself.

Thanks for any tips!
Photo of Heitor Moraes

Heitor Moraes

  • 100 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 3
Photo of Frank


  • 3,806 Points 3k badge 2x thumb
I see the same with 15.4.3 p1-10 and
The command looks fine - I was wondering if it didn't like closing without "exit", so I did:
ssh -v user@switch "exit"
but that, too, gave me a "-1", i.e. "255"

Heck, even on an interactive ssh session, once you type "exit", the return code is -1/255

Do we need to open a case?
Photo of Drew C.

Drew C., Community Manager

  • 40,218 Points 20k badge 2x thumb
Interesting.  Definitely sounds like it is worthy of opening a case to track.
I'll let you two flip a coin :)

Photo of Frank


  • 3,806 Points 3k badge 2x thumb
OK, I'll open one :)
Photo of Heitor Moraes

Heitor Moraes

  • 100 Points 100 badge 2x thumb
I did it already! I was just waiting for the first response from support before posting here.
Photo of Leandro Brito

Leandro Brito, Alum

  • 232 Points 100 badge 2x thumb
I got a different result here:

lbrito@LW540 ~ $ ssh admin@ "show version"Keyboard-interactive authentication
Enter password for admin: 
Keyboard-interactive authentication
Enter password for admin: 
Switch      : 800472-00-08 1246G-01386 Rev 8.0 BootROM:    IMG:  
PSU-1       : Internal Power Supply  
PSU-2       :

Image   : ExtremeXOS version v1571b4-patch1-2 by release-manager
          on Fri May 1 15:16:42 EDT 2015
BootROM :
Diagnostics : 6.3

lbrito@LW540 ~ $

I'll try with 15.4.3 p1-10, and and will share the results this afternoon with you.
Photo of Jan Steinbach

Jan Steinbach

  • 1,192 Points 1k badge 2x thumb
Thx Leandro, but I miss the "echo $?" in your bash output ;-)
Photo of Leandro Brito

Leandro Brito, Alum

  • 232 Points 100 badge 2x thumb
On further investigation by the developer , It seems like client sends disconnect message when it is done with remote command execution, ssh-toolkit server is not able to decode this message properly, and kills the session with SIGTERM.

That's why client doesn't receive any exit status and it shows status as 255 or -1(error case).

A CR xos0063330 was created to solve that.

I'll keep you guys updated.
Photo of Henrique

Henrique, Employee

  • 10,342 Points 10k badge 2x thumb

Regarding CR xos0063330, the development team has further investigated the problem and have found that this issue appears only in our older SSH Server, which is a  SSH-toolkit implementation. From EXOS 16.2 and above releases, we are using OpenSSH for SSH server and this issue is not observed. 

SSH-Toolkit Server supports only the below listed SSH-request types. Here "exec" is used for remote command execution, which works fine. But after the command is executed the client will request for a "exit-status" from the server. In SSH-Toolkit server, this message type is not supported. So, for "exit-status" request, Server replies with an error message. This is because it cannot process the request.

The valid channel requests in SSH-Toolkit and their actions are:   

    "pty-req"       -- setup pty
    "shell"         -- start user shell
    "exec"          -- execute a command
    "subsystem"     -- handle subsystem calls (not implemented yet)
    "env"           -- determine if ENV variable is OK to be set, then set
    "signal"        -- if we have signals, send this signal to the process
    "exit-status"   -- send exit status to client, close connection (not supported - ignored)
    "window-change" -- change terminal window size values
    "xon-xoff"      -- handle flow control (not supported - ignored)
    "x11-req"       -- channel request failure (not supported - ignored)

In EXOS 16.2 and 21.1 releases this issue (CR xos0063330) would not exist as we have upgraded the SSH server to OPENSSH instead of SSH-Toolkit. However for EXOS releases lower than 16.2, this limitation would continue to exist.