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

2018-11-09 Thread W. Michael Petullo
>>> 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 
> 
> 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


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

2018-11-09 Thread Matt Johnston
Hi Michael,

On 2018-11-09 3:48 pm, W. Michael Petullo wrote:
>> 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 

Now the exit code check happens before the line you noted. Somehow that 
got missed in CHANGES.

Cheers,
Matt