ssh won't work from initial ram disk in 2.4.18

ssh won't work from initial ram disk in 2.4.18

[Rob Landley]

I'm using a 2.4.18 kernel and ssh 3.0.2, and I'm trying to run ssh from the 
initrd, and it's refusing to work.  The exact same setup works booted from a 
small partition, but if I take a tarball of that filesystem and dump it into 
a ramdisk, ssh always fails to authenticate.  (Public key or password, it 
doesn't matter.  When I run it from sh in initrd, it doesn't even prompt me 
for a password, just prints out three failure messages and exits.  The same 
setup from /dev/hda1 works just fine...)

Both filesystems (/dev/hda1 and the initrd.img) are formatted ext3.  (Because 
ext2 support is a seperate driver I'd have to compile in, the journal size is 
1 meg.  The initrd is 16 megs, and yes I upped the default ramdisk size to 16 
megs.  The box itself has 128 megs of ram.)  Modules are disabled.

(In case you're wondering, I'm running dhcpcd, which is happy, followed by a 
variant of "ssh 10.0.0.1 cat yourbrain.sh | /bin/bash".  The reason I need to 
make it run from a ramdisk is that the script I'm trying to suck accross will 
repartion the box, format the partitions, and untar a big tarball into it.  
It's quick and dirty a system manufacturing thing.  sfdisk won't reread the 
partition table if you have any partitions from the drive, and a reboot 
between "partition" and "format" stages is, um, problematic.)

As I said, it works fine when it's NOT running from an initial ramdisk.  ssh 
connects and has no problem transferring data.  But from a ramdisk, instant 
failure, either password or public key pair.  I don't even get to ENTER my 
password.  (Run /bin/bash and try to ssh as root.  It WILL prompt me about 
the box's fingerprint not being recognized, but it immediately goes 
"Permission denied, please try again." three times for the password without 
lettiing me type anything.)

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.)

If somebody wants a tarball of this test case, drop me an email.  It's only a 
couple megabytes...

Rob

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

[Sean Neakums]

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.

-- 
 /////////////////  |                  | The spark of a pin
<sneakums@zork.net> |  (require 'gnu)  | dropping, falling feather-like.
 \\\\\\\\\\\\\\\\\  |                  | There is too much noise.

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

[Rob Landley]

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 10.0.0.1 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.  :)

Rob

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

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Thu, Mar 28, 2002 at 07:28:05AM -0500, Rob Landley wrote:
> I'm using a 2.4.18 kernel and ssh 3.0.2, and I'm trying to run ssh from the 
> initrd, and it's refusing to work.  The exact same setup works booted from a 
> small partition, but if I take a tarball of that filesystem and dump it into 
> a ramdisk, ssh always fails to authenticate.  (Public key or password, it 
> doesn't matter.  When I run it from sh in initrd, it doesn't even prompt me 
> for a password, just prints out three failure messages and exits.  The same 
> setup from /dev/hda1 works just fine...)

ssh tries to talk to your console.
Which apparently has not yet been assigned / set up.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]