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

[W. Michael Petullo]

>> Here is a more practical example which demonstrates the problem:
>> 
>> $ echo false | dbclient -T r...@host.example.com
>> $ echo $?
>> 0
> 
> I think this should now _really_ be fixed with
> https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9
> 
> dbclient was ignoring all packets for channels that were in the process
> of being closed, which included exit status messages.

This seems to work. I applied this change to an otherwise vanilla
dropbear-2018.76, and it seemed to solve the problem.

Thank you!

-- 
Mike

:wq

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

[Matt Johnston]

Hi Mike,

> On Sat 10/11/2018, at 12:52 am, W. Michael Petullo  wrote:
> 
> 
> Here is a more practical example which demonstrates the problem:
> 
> $ echo false | dbclient -T r...@host.example.com
> $ echo $?
> 0

I think this should now _really_ be fixed with
https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9

dbclient was ignoring all packets for channels that were in the process of 
being closed, which included exit status messages.

Cheers,
Matt

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

[Peter Krefting]

2018-11-10 12:53 skrev W. Michael Petullo:

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?


You're right and I am wrong. The exit code is the right-most command.

Sorry for the confusion.

--
\\// Peter - http://www.softwolves.pp.se/

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

[u-pwhy]

On Sat, Nov 10, 2018 at 10:44:03AM +0100, Peter Krefting wrote:
> >$ echo false | dbclient -T r...@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 feel this deserves correction and clarification, because it is possible
to encounter contradicting statements from different sources.

Long ago the status reporting from a shell pipe was a contentious
issue, the rules varied with time and between different shells.

Nowadays it is consistent, reporting the status of the _last_ command
in the pipe:

$ false | true; echo "$?"
0
$ true | false; echo "$?"
1

The cited link above discusses reporting of status from some member of
the pipe which is _not_ the rightmost, in a modern shell.

Cheers,
Rune

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

[W. Michael Petullo]

>> Here is a more practical example which demonstrates the problem:
>> 
>> $ echo false | dbclient -T r...@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 r...@host.example.com
$ echo $?
1

Here is the complete set of exit codes:

$ echo false | dbclient -T r...@host.example.com
$ echo "${PIPESTATUS[0]} ${PIPESTATUS[1]}"
0 0
$ echo false | ssh -T r...@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

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

[Peter Krefting]

2018-11-09 17:52 skrev W. Michael Petullo:


Here is a more practical example which demonstrates the problem:

$ echo false | dbclient -T r...@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


--
\\// Peter - http://www.softwolves.pp.se/

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

[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

[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

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

[W. Michael Petullo]

> I am using Dropbear v2017.75 as found on OpenWrt.
> 
> I am building a system around a special shell which exits with the value
> of `1' upon encountering certain errors. Let us assume this shell runs
> on the host "h." My aim is that the following will print `1' if such an
> error occurs (using Dropbear's ssh to Dropbear's sshd):
> 
>   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.
> 
> When I run this (using Dropbear's ssh to Dropbear's sshd):
> 
>   ssh -T h; echo $?
> 
> and manually provide the input by typing "input," the result is `1'
> as expected.
> 
> Something from using "-T" and also taking input from a pipe seems to
> cause ssh or sshd to malfunction in the earlier case.
> 
> When I repeat these commands using OpenSSH's ssh to connect to Dropbear's
> sshd, the output is `1' in both cases. This is the expected behavior.
> 
> Does anyone have an idea of what might be causing this? Is there indeed
> a bug related to "-T" plus stdin from a pipe?

After looking at the code, it appears this block in common-channel.c is
the culprit (line 346):

if (channel->readfd == FD_CLOSED
&& channel->writefd == FD_CLOSED
&& (ERRFD_IS_WRITE(channel) || channel->errfd == 
FD_CLOSED)
&& !channel->sent_close
&& close_allowed
&& !write_pending(channel)) {
TRACE(("sending close, readfd is closed"))
send_msg_channel_close(channel);
}

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 do not yet know the code well enough to know if I have this right, but
replacing send_msg_channel_close with send_msg_channel_eof does result in
the correct exit code. Removing this block entirely also causes the same.

Any idea what the correct solution is?

-- 
Mike

:wq

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

[W. Michael Petullo]

I am using Dropbear v2017.75 as found on OpenWrt.

I am building a system around a special shell which exits with the value
of `1' upon encountering certain errors. Let us assume this shell runs
on the host "h." My aim is that the following will print `1' if such an
error occurs (using Dropbear's ssh to Dropbear's sshd):

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.

When I run this (using Dropbear's ssh to Dropbear's sshd):

ssh -T h; echo $?

and manually provide the input by typing "input," the result is `1'
as expected.

Something from using "-T" and also taking input from a pipe seems to
cause ssh or sshd to malfunction in the earlier case.

When I repeat these commands using OpenSSH's ssh to connect to Dropbear's
sshd, the output is `1' in both cases. This is the expected behavior.

Does anyone have an idea of what might be causing this? Is there indeed
a bug related to "-T" plus stdin from a pipe?

--
Mike

:wq