seeding dev/random in 5.5

[R. B. Riddick]

--- Michael Scheidell <scheidell at secnap.net> wrote:
> I was doing some regression testing in 5.5: Specifically testing booting
> up a 'virgin' hard disk from a clean install.
> 
> I was testing what happened if the 300 second timeout happened vs
> hitting <return> for 'fast+insecure' startup and punching in a bunch of
> random garbage.
> 
> I found that for some reason, on a 2.4Ghz Celeron, the 'sysctl -a' and
> 'date' seeding for 'fast+insecure' seemed to do nothing unless I typed
> in at least 3 lines of random keystrokes.
> 
> ie: /etc/rc.d/sshd start WONT, it doesn't generate ssh keys in /etc/ssh
> and ssh won't start.
> 
> Is there something in /dev/random that won't init if it isn't random enough?
> 
> (if doing this from an unattended bootup, expecting the 300 second
> timeout, I find that sshd does not start!)
> 
> After doing some testing, it appears that (at least with the combination
> of a 2.4Ghz Celeron and 5.5) that it takes at least three lines of
> random data, added to the output of sysctl -a and date to seed /dev/random.
> 
> (as per this in /etc/rc.d/sshd:
>                read -t ${timeout} junk
>                 echo "${junk}" `sysctl -a` `date` > /dev/random
> 
> I can find no other explanation to the results of my tests:
> 
> This removes keys:
> /etc/rc.d/sshd stop
> rm /etc/ssh/*key*
> /etc/rc.d/sshd start
> 
> tests:
> 
> #1, allow 300 second timeout:
> remove keys, restart sshd: /etc/rc.d/sshd start
> let it sit for 300 seconds.
> No error messages, but sshd doesn't start, and there are no keys in /etc/ssh
> 
> #2, one line of random test
> (same results as above)
> #3, two lines, etc
> 
> #4, three lines.
> Now, I get the messages telling me that ssh_keygen has created keys, and
> there are keys in /etc/ssh
> 
> I also find that by adding this to the random seeding that it will work
> with <return> or 300 second timeout:
> 
>                read -t ${timeout} junk
>                 echo "${junk}" `sysctl -a` `date`  `tcpdump -xs1500 -c
> 5` > /dev/random
> 
> Yes, I know, but even ;lj;lkj;lj;ljjl on the keyboard isn't all that
> random, but my issue is not being able to remotely access a virgin
> system with ssh.  Sometimes these are headless pizza boxes, buried deep
> in the bowels of some data center.
> 
> Has anyone else run tests like this?
> 
> (I suppose the -c value in tcpdump could be random as well '-=) using:
> 
> count = `date "+%S"`
> 
> In a remote location, with no head, no monitor, its hard trying to
> figure out just WHY 'system won't boot'.
> (it booted, but sshd didn't start!)
> 
> There is enough random[pun intended] things that can happen when you
> install a new system, that I would like to try to eliminate one of them.
> 
I think that during the first reboot after a fresh install the kern.random.sys
sysctl settings are already orderly before rc.d/sshd is called...

If yes, then sending some pings should do the trick... Or not?
I mean: NETWORKING should already be provided at that point...

Btw.: 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com