exit-signal sent, but ignored

[Christian Weisgerber]

I've been puzzling over the disparate exit codes returned by ssh
when the remote command is killed by a signal:

$ ssh host1 'kill -HUP $$'; echo $?
129
$ ssh host2 'kill -HUP $$'; echo $?
255

This results from the interaction of
(a) the behavior of the login shell and
(b) an implementation gap in OpenSSH's ssh(1) client.

If the login shell is bash, its exit triggers the WIFSIGNALED()
check in session_exit_message() and an "exit-signal" message is
sent.  However, client_input_channel_req() does not handle
"exit-signal" at all, exit_status is not set and retains its
initial value -1.  Therefore ssh returns 255.

If the login shell is OpenBSD's ksh, its exit triggers the WIFEXITED()
check instead and an "exit-status" message is sent.  This is handled
in client_input_channel_req, and ssh returns the received exit code
of 128 + signal.

This is not the place to discuss the correctness of the respective
shell behavior.

However, shouldn't ssh(1) handle "exit-signal" and synthesize an exit
status of 128 + signal?

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de