Strange behaviour surrounding "ssh -T ..." and non-zero exit

W. Michael Petullo mike at flyn.org
Sat Nov 10 19:53:14 AWST 2018


>> Here is a more practical example which demonstrates the problem:
>> 
>> $ echo false | dbclient -T root at host.example.com
>> $ echo $?
>> 0
 
> That is because $? contains the exit status of the left-most command (echo),
> not the pipe. If you are using a bash shell, you need to use PIPESTATUS to
> find it, read more at: https://unix.stackexchange.com/a/73180

I read the reference you provided, but I am not yet convinced.  Is it not
true that pipelines by default produce the exit code from the right-most
program in the pipeline?

"echo false" should run locally and exit with `0.'  dbclient should invoke
a remote shell which reads "false" from stdin and executes false. The
remote execution of false should produce an exit code of `1,' and thus
dbclient should also produce an exit code of `1.'  The over-all exit
code should be `1.'

In contrast, OpenSSH's client behaves as I expect:

$ echo false | ssh -T root at host.example.com
$ echo $?
1

Here is the complete set of exit codes:

$ echo false | dbclient -T root at host.example.com
$ echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"
0 0
$ echo false | ssh -T root at host.example.com
$ echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"
0 1

Dropbear behaves as I would expect if I modify it in the way I previously
described.  As I have mentioned, my proof-of-concept changes probably break
other things because it is not yet clear to me how to properly fix this.

-- 
Mike

:wq


More information about the Dropbear mailing list