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