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 [EMAIL PROTECTED] "echo hello"
[EMAIL PROTECTED]'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 ([EMAIL PROTECTED]) Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd. Phone: (715) 726-8410
Chippewa Falls, WI 54729 Fax: (715) 726-6715
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
