Strange behaviour surrounding "ssh -T ..." and non-zero exit
W. Michael Petullo
mike at flyn.org
Sat Nov 10 00:52:14 AWST 2018
>>> I am using Dropbear v2017.75 as found on OpenWrt.
>>>
>>> echo input | ssh -T h; echo $?
>>>
>>> Despite the error occurring, the above command line prints `0' rather
>>> than `1.' Since this triggers the error, I would expect the latter
>>> instead.
>> After looking at the code, it appears this block in common-channel.c is
>> the culprit (line 346):
>> I think ssh is reaching the EOF on stdin, and then this block causes
>> the
>> channel to close before it reads the exit code from the distant end.
> I think this problem might be fixed in v2018.76,
> https://secure.ucc.asn.au/hg/dropbear/rev/0c16b4ccbd54#l4.46 <https://secure.ucc.asn.au/hg/dropbear/rev/0c16b4ccbd54#l4.46>
> Now the exit code check happens before the line you noted. Somehow that
> got missed in CHANGES.
The problem seems to remain in dropbear-2018.76. Like with my
previous email about dropbear-2017.75, adjusting the call of
send_msg_channel_close(channel) seems causes dbclient to obtain the
correct exit code, albeit with unknown effect on the rest of the logic
in the program.
Here is a more practical example which demonstrates the problem:
$ echo false | dbclient -T root at host.example.com
$ echo $?
0
--
Mike
:wq
More information about the Dropbear
mailing list