i reported this some months ago.
i still use this:
===
===
diff -r -u -N openssl-0.9.7a.orig/crypto/rand/rand_unix.c
openssl-0.9.7a/crypto/rand/rand_unix.c
--- openssl-0.9.7a.orig/crypto/rand/rand_unix.c Thu Nov 28 09:08:40 2002
+++ openssl-0.9.7a/crypto/rand/rand_unix.c Fri Feb 28 11:41:25 2003
@@ -159,8 +159,8 @@
#endif
)) >= 0)
{
- struct timeval t = { 0, 10*1000 }; /* Spend 10ms on
- each file. */
+ struct timeval t = { 15, 0 }; /* Spend 15s on
+ each file. */
int r;
fd_set fset;
@@ -185,11 +185,11 @@
up here, otherwise, we will do
this once again for the remaining
time. */
- if (t.tv_usec == 10*1000)
- t.tv_usec=0;
+ if (t.tv_sec == 15)
+ t.tv_sec=0;
}
while ((r > 0 || (errno == EINTR || errno == EAGAIN))
- && t.tv_usec != 0 && n < ENTROPY_NEEDED);
+ && t.tv_sec != 0 && n < ENTROPY_NEEDED);
close(fd);
}
===
patch to compile openssl. that way openssh starts all the time on solaris.
niki
> 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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
