>>> 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 r...@host.example.com $ echo $? 0 -- Mike :wq