seeding dev/random in 5.5

Michael Scheidell scheidell at secnap.net
Mon Aug 7 22:02:10 UTC 2006


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.


-- 
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
scheidell at secnap.net  / 1+561-999-5000, x 1131



More information about the freebsd-security mailing list