MAX_USERNAME_LEN set too low

[W. Michael Petullo]

Dropbear's auth.h defines MAX_USERNAME_LEN as 25 and provides the
commentary "arbitrary for the moment."

The useradd utility from shadow-utils on Linux supports usernames with
up to 32 characters.

This means that some valid users cannot make use of SSH, namely users
for which len(username) is larger than 25 but less than 32.

32 seems pretty common. Can we modify Dropbear to use 32 instead of 25?

-- 
Mike

:wq

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

[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

[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

[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