
#To:		openssh-unix-dev@mindrot.org,
		openssl-bugs@openssl.org,
		support@aus.sun.com

#From:		henryg@optimation.com.au
		Henry Grebler, Optimation Software Engineering Pty Ltd




Hi,


I can't tell if I have a problem with OpenSSH, OpenSSL or with Sun's
/dev/random (or some combination).

On a Netra t1 running Solaris 9,  at boot time, I'm getting these
messages: 

starting /usr/local/sbin/sshd... PRNG is not seeded
/etc/rc2.d/S98opensshd: Error 255 starting /usr/local/sbin/sshd... bailing.

I'm running:

OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003

I've spent a bit of time investigating and trussing, and have surmised
or discovered the following:

I have cut down the number of tasks that get started. At the time that
S98opensshd is run only 11 processes are running. On a typical Solaris
system, one could expect 30 processes to be running at the time sshd
is started.

Sun's sshd (which seems to have a different pedigree) uses
/dev/urandom (notwithstanding their comments in random(7D) about the
quality of random numbers).

In fact, /dev/random seems to be able to supply random numbers fairly
rapidly, but it seems it needs a "kick-start". On several occasions,
after sshd had failed to start at boot time, I tried to start it
manually using the same command and repeatedly got the same error
message. I was even able to truss the problem. If I persevere,
eventually, I can get the daemon to start.

Once it starts, I have tried unsuccessfully to drain /dev/random and
get it to fail again.

I have built a trivial solution to the problem which I have
implemented as a startup script (S97opensshd_helper) which uses dd to
get 1024 random numbers from /dev/random; it then cats them back to
/dev/random. This seems to be enough to satisfy OpenSSL. I'm sure it's
overkill, but it does the job. S97opensshd_helper only takes 1 second
to get enough random numbers to start the ball rolling.

There is a large amount of variation in how fast /dev/random can
supply 1024 random bytes. I have clocked speeds as high as 26 MB/s. If
/dev/random is drained, it tends to settle down to a rate of about 4
KB/s. 

At the point where it is failing, sshd (via OpenSSL) is only
requesting 32 bytes.


Sun's /dev/random seems to be able to accumulate quite a large number
of random bytes over time. It strikes me as odd that there seems to be
no mechanism for storing a pool of these bytes between reboots.

OpenSSL allows for alternate sources of random numbers; these must be
pipes. For its own program, openssl, it allows the use of a storage
file which can be set using an environment variable, RANDFILE. It
seems that this mechanism is not available to applications which use
the OpenSSL libraries.


As I said, I have a workaround. It's not elegant, but it's adequate. I
raise this issue in the hope that I've overlooked something.


Regards,
Henry


