scp client hangs after authentication with dropbear server

[Steven Hein]

Grrrr...... figured it out, finally!   This is nothing to do with dropbear
or busybox!    The problem was that my root filesystem had a script
called "/bin/bash", that simply exec's /bin/sh, but doesn't pass the 
arguments!
And my root user was using /bin/bash as its shell.   So, when 
execchild() called
my shell (/bin/bash), the args never got passed to the shell!    I have 
no idea
why this would be a good idea......    Once I changed my root user to use
/bin/sh as its shell, everything worked fine!     (I didn't realize all 
of this
until I tried to execute the same command that ssh was trying to execute
remotely, i.e.    /bin/bash -c 'echo hello'     When I saw that start a 
new shell
but not do the command, I found the problem quickly).

Anyway, sorry for the bother, and thanks for looking at it!
(FYI, I'm using TimeSys LinuxLinux subscription service as the source for
my rootfilesystem RPMs......and the bad /bin/bash shell I mentioned above
is in one of their RPMs!   Just a warning for any other TimeSys users).

Steve



Steven Hein wrote:

> Matt Johnston wrote:
>
>> On Wed, Feb 07, 2007 at 11:58:55AM -0600, Steven Hein wrote:
>>  
>>
>>> Steven Hein wrote:
>>>
>>>   
>>>
>>>> I have the dropbear server running on a PPC-based embedded board.
>>>> I can ssh into it just fine.   But when I try to scp to or from
>>>> this dropbear server (using an openssh scp client, that's the only
>>>> one I've tried), it hangs after successful authentication with
>>>> a password.
>>>>     
>>>
>>
>> I don't recall seeing this problem before - as you noted
>> previous issues with scp have been it hanging after
>> finishing. From the strace, can you see what the server scp
>> process is doing? If you could send me the full output of
>> "strace -f -o trace1.out ./dropbear -F -E ...etc" I'll see
>> what I can make of it. If you compile Dropbear with
>> DEBUG_TRACE set in debug.h you can use the -v flag to print
>> some more verbose output of what's happening - note that
>> inetd mode won't work when you're using that.
>>
>> The output of scp -vvv might also give some clues. One other
>> thought is that it might be running out of entropy in the
>> reseedrandom() call in execchild() - does using /dev/urandom
>> for DROPBEAR_RANDOM_DEV in options.h help (I doubt it)?
>>
>> Cheers,
>> Matt
>>  
>>
> I'll try these suggestions shortly.   Just a couple more data
> points from yesterday.   I get the same sort of hang if I
> try to execute a command from ssh:
>
> # ssh root at essc1 "echo hello"
> root at essc1's password:
> <hangs here until I CTRL-C>
>
> So, it seems that this is related to executing a remote command
> through ssh (which is what scp needs to do, right?  execute a command
> on the dropbear server side?).   This seems to suggest a problem
> in execchild().   But....I have /dev/random symlink'd to /dev/urandom
> as I seem to have 0 entry available on my system for some reason....
>
> One other bit:   the shell on the dropbear server side is
> busybox--any problems related to that?
>
> I'll post the results of the experiments shortly.
>
> Steve
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Hein (ssh at sgi.com)              Engineering Diagnostics/Software
Silicon Graphics, Inc.                          
1168 Industrial Blvd.                 Phone: (715) 726-8410
Chippewa Falls, WI 54729              Fax:   (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~