Dropbear 0.50 server returnsexit code 255 to ssh when app returns 0

roger at planbit.co.uk roger at planbit.co.uk
Sat Dec 1 01:41:29 WST 2007


> More information appended...
>
>> Hi,
>>
>> We are running the Dropbear 0.50 SSH server on an ARM9 platform.  We are
>> connecting to it from a fast quad-core intel server over 100-Base-T.
>>
>> We found this problem when trying to build Perl for the target.  The
>> cross-compile process uploads and runs programs on the target and checks
>> the exit code from the SSH client to check the target program's exit
>> code.
>>
>> The ARM9 platform is running a stock Linux 2.6.18 kernel compiled with
>> the
>> GCC CodeSourcery 2006q3-26 v4.1.1.
>>
>> The host Intel platform is running CentOS5 with OpenSSH_4.3p2.
>>
>> A sample shell script on the target is:
>>
>> #!/bin/bash
>> echo "ARG: $1"
>> exit $1
>>
>> When we run dropbear 0.50 server on the target without debug enabled, we
>> get exit code 255 from SSH.  e.g.
>>
>> # ssh root at 192.168.0.10 /tmp/test.sh 1
>> ARG: 1
>> # echo $?
>> 255
>> #
>>
>> # ssh root at 192.168.0.10 /tmp/test.sh 100
>> ARG: 1
>> # echo $?
>> 255
>> #
>>
>> If we recompile dropbear with debug enabled, but don't pass the -v
>> option
>> when starting dropbear, the behavior is the same.  If we run dropbear
>> with
>> the "-F -E -v" options, we get the correct exit codes.
>>
>> # ssh root at 192.168.0.10 /tmp/test.sh 1
>> TRACE: enter sign_key_free
>> TRACE: enter dsa_key_free
>> TRACE: enter dsa_key_free: key == NULL
>> TRACE: enter rsa_key_free
>> TRACE: leave rsa_key_free
>> TRACE: leave sign_key_free
>> ARG: 1
>> # echo $?
>> 1
>> #
>>
>> # ssh root at 192.168.0.10 /tmp/test.sh 100
>> TRACE: enter sign_key_free
>> TRACE: enter dsa_key_free
>> TRACE: enter dsa_key_free: key == NULL
>> TRACE: enter rsa_key_free
>> TRACE: leave rsa_key_free
>> TRACE: leave sign_key_free
>> ARG: 1
>> # echo $?
>> 100
>> #
>>
>> Does anyone have any ideas what could be causing this?
>>
>> Has anyone seen this on other platforms or is happy that dropbear does
>> return the correct exit codes in their tests?
>>
>> Thanks,
>>
>> Roger
>>
>
> I have upgraded the host to OpenSSH 4.7 and the problem persists.
>
> Turning on full logging on the host provides the following end trace on a
> failing connection (when dropbear is not generating logging output to the
> serial terminal):
>
> debug2: channel 0: open confirm rwindow 8000 rmax 8000
> ARG: 100
> debug2: channel 0: rcvd eof
> debug2: channel 0: output open -> drain
> debug2: channel 0: obuf empty
> debug2: channel 0: close_write
> debug2: channel 0: output drain -> closed
> debug2: channel 0: rcvd close
> debug2: channel 0: close_read
> debug2: channel 0: input open -> closed
> debug3: channel 0: will not send data after close
> debug2: channel 0: almost dead
> debug2: channel 0: gc: notify user
> debug2: channel 0: gc: user detached
> debug2: channel 0: send close
> debug2: channel 0: is dead
> debug2: channel 0: garbage collecting
> debug1: channel 0: free: client-session, nchannels 1
> debug3: channel 0: status: The following connections are open:
>   #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
>
> debug3: channel 0: close_fds r -1 w -1 e 7 c -1
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status -1
>

TYPO: Below should read ..."when dropbear is generating logging"...   The
cut-and-paste daemon strikes again!

>
> On a working connection, when dropbear is not generating logging output to
> the serial terminal, following end trace is gathered:
>
> debug2: channel 0: written 106 to efd 7
> ARG: 100
> debug2: channel 0: rcvd eof
> debug2: channel 0: output open -> drain
> debug2: channel 0: obuf empty
> debug2: channel 0: close_write
> debug2: channel 0: output drain -> closed
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug2: channel 0: rcvd close
> debug2: channel 0: close_read
> debug2: channel 0: input open -> closed
> debug3: channel 0: will not send data after close
> debug2: channel 0: almost dead
> debug2: channel 0: gc: notify user
> debug2: channel 0: gc: user detached
> debug2: channel 0: send close
> debug2: channel 0: is dead
> debug2: channel 0: garbage collecting
> debug1: channel 0: free: client-session, nchannels 1
> debug3: channel 0: status: The following connections are open:
>   #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)
>
> debug3: channel 0: close_fds r -1 w -1 e 7 c -1
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.5 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 100
>
>
> With the working connection, we get the "client_input_channel_req" event
> coming in whereas in the failing connection, it doesn't occur.
>
> Does this information give anyone a clue/suggestion as to what may be
> failing?
>
> Thanks.
>





More information about the Dropbear mailing list