cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 

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

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

Heitor_Moraes
New Contributor
Hi,

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?

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

#> echo $?
255
#>
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!
H.
8 REPLIES 8

Henrique
Extreme Employee
Hi,

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.

Leandro_Brito
Extreme Employee
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.

Drew_C
Valued Contributor III
Interesting. Definitely sounds like it is worthy of opening a case to track.
I'll let you two flip a coin šŸ™‚

-Drew

Thx Leandro, but I miss the "echo $?" in your bash output šŸ˜‰
GTM-P2G8KFN