#To: [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
#From: [EMAIL PROTECTED]
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
