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