Re: ssh won't work from initial ram disk in 2.4.18

Rob Landley (
Thu, 28 Mar 2002 09:00:50 -0500

On Thursday 28 March 2002 08:20 am, Sean Neakums wrote:
> commence Rob Landley quotation:
> > If this is an ssh problem I'll be happy to go bug those guys, but
> > why would it be different from initrd than from an actual mounted
> > partition? (Permissions are the same, I checked.)
> Have you tried running ssh with the -v switch? That will dump a bunch
> of debug info that's often very helpful with investigating problems
> such as these.

Yup. I broke out the ssh source code to see what the messages meant, too.
(It's a linux from scratch system. Comes in handy at times like these. :)

Cutting and pasting from this test case is a bit problematic, but the most
interesting message was the one where it was complaining I hadn't entered the
passphrase for the public key. (The key doesn't HAVE a passphrase. Yes I
compared the id_dsa files, authorized_keys, etc.) This is probably a red
herring though, since the non-passphrase version (ssh as root) has a
similar behavior of complaining I hadn't entered a password it had never
prompted me for. It seems to get an immediate eof (or some other kind of
error) on input whenever it wants a password.

Again, the exact same code and data files work after initrd exits.

It MIGHT have something to do with the fact that ptys don't seem to be
initialized before initrd exits. ssh gets a little strange when there are no
ptys. (When I mount /dev/pts, it's empty. However, the success case of
booting the same code from /dev/hda1doesn't even need /dev/pts mounted to
work, so...?)

I can probably cut this test case down to fit on a bootable floppy given
about eight hours of sleep. :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at