I get these errors while running a Korn shell script which runs installations on multiple servers from a single server location. some processes are run in background such as copying files to the servers. During the copy process at different times between the 5th and 7th process I get these errors. PRNG seed extraction failed ssh-rand-helper child produced insufficient data I have no clue as to what is going on but this same script worked under the previous version of ssh that only supported ssh1. Can anyone please help.
Created attachment 757 [details] deploy korn script that distributes and installs application software on multiple servers. This is the script.
Created attachment 758 [details] sshd_config file sshd_config file
To figure out what the random helper program is doing (or not doing, as the case may be) try running "ssh-random-helper -vvv" multiple times, checking if it fails sometimes and comparing the output between runs. You'll probably get better results if you install prgnd: http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html If your OpenSSL is relatively modern, it will search the default places for the prngd socket so you won't need to recompile OpenSSH after installing prngd, it will be used automatically. BTW, what version of SunOS are you running?
Created attachment 759 [details] log of ssh-rand-helper -vvv
Darren, Thanks for your response. running "uname -a" produces the following. SunOS NNM2 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-2 I have run ssh-rand-helper -vvv and supplied a log. I ran this command atleast 25 time and also created a script to run it in background mode and recieved no errors. I am not sure of the openssh imstall was done correctly. I am just a user and the SA's don't seemed to be as bothered as me about this problem.
Created attachment 760 [details] Use temporary file for prng_seed I wonder if this is a race condition in prng_seed creation/reading. Please give this patch a try and see if it helps. You might also want to try some stress-tests on ssh-rand-helper. E.g. something like this: for x in 0 1 2 3 4 5 6 7 8 9; do for y in 0 1 2 3 4; do sh -c "ssh-rand-helper -vvv > out.$x.$y 2>&1 || echo $x.$y failed" & done ; done This will run 50 concurrent ssh-rand-helpers, and should report on failures.
Heh. Don't try that script on a production box, kids (or at least, not in prime time): $ uptime 7:42pm up 19 min(s), 3 users, load average: 54.55, 28.04, 14.86 Anyway, I can reproduce it on Solaris 2.5.1. Here's the tail of a failing log: debug3: Got 0.00 bytes of entropy from 'tail -200 /var/adm/messages' debug1: Seeded RNG with 4 bytes from programs debug1: writing PRNG seed to file /home/dtucker/.ssh/prng_seed PRNG seed extraction failed Will test patch #760 next.
The patch made no difference for me (although it still seems like a good idea). I took a closer look at the logs and the problem appears to be that all of the commands time out before providing any entropy, eg: debug3: Reading output from 'uptime' debug3: Time elapsed: 1073 msec debug2: Command 'uptime' timed out I don't see what ssh-rand-helper can do about that aside from upping the timeout. Stephen, I suggest you ask your admins to install Sun patch 112438-03 (assuming the box is a SPARC). Installing it by the book requires a reboot, but there are instructions around for loading the module and creating the device nodes by hand.
Comment on attachment 760 [details] Use temporary file for prng_seed I'd like this patch to go in for the next release.
Created attachment 827 [details] add a dummy seed_rng to placate HP-UX's linker Since the patch uses strlcpy the linker now must pull in libopenbsd-compat for ssh-rand-helper for platforms that don't have it natively. Unfortunately, it appears that the HP-UX linker wants to resolve all of the external symbols even if they're only used in functions not ultimately used in the binary, and blows up thusly: gcc -o ssh-rand-helper ssh-rand-helper.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -lssh -lopenbsd-compat -lcrypto -lz -lnsl -lxnet -lsec /usr/ccs/bin/ld: Unsatisfied symbols: seed_rng (first referenced in openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o)) (code) The attached patch adds a dummy seed_rng. With this patch and #760 it builds OK.
Comment on attachment 760 [details] Use temporary file for prng_seed OK, subject to comment #10.
Comment on attachment 827 [details] add a dummy seed_rng to placate HP-UX's linker Instead of doing nothing, could you make it spectacularly fprintf(stderr) and exit(1)? If ssh-rand-helper ever somehow starts using arc4random, then it would do so with an unseeded RC4... Otherwise OK
Comment on attachment 827 [details] add a dummy seed_rng to placate HP-UX's linker > arc4random calls seed_rng so we need a dummy seed_rng. Should also mention it's specifically the arc4random in libopenbsd-compat.
Yes, that is a good idea. BTW the mkstemp+rename thing is in now, so please commit your linker fix soon.
(In reply to comment #12) > (From update of attachment 827 [details] [edit]) > Instead of doing nothing, could you make it spectacularly fprintf(stderr) and > exit(1)? If ssh-rand-helper ever somehow starts using arc4random, then it > would do so with an unseeded RC4... Unfortunately, it doesn't seem to be that simple. seed_rng() *does* get called right after all the processing but immediately before the output is written (although I don't understand why). If you believe gdb it's called by OpenSSL's CRYPTO_free() but that seems pretty wacky. I put a debug in seed_rng and set a breakpoint on it: #0 seed_rng () at ../../ssh-rand-helper.c:901 #1 0x0000f78c in CRYPTO_free () #2 0x000079d8 in _gettemp ( path=0x7f7e0ec8 "/home/dtucker/.ssh/prng_seed.XXXXX13501", doopen=0x7f7e1348, domkdir=0, slen=0) at ../../../openbsd-compat/mktemp.c:105 #3 0x00007b70 in mkstemp ( path=0x2a10980 <Error reading address 0x2a10980: Bad address>) at ../../../openbsd-compat/mktemp.c:61 #4 0x00005d40 in prng_write_seedfile () at ../../ssh-rand-helper.c:585 #5 0x000067d8 in main (argc=2, argv=0x7f7e0500) at ../../ssh-rand-helper.c:866 Hey, gettemp() *does* call arc4random(), which calls seed_rng() so it looks like I was wrong in blaming the linker. Checking RAND_status() seems to be the right thing to do.
Created attachment 828 [details] provide seed_rng() and document why it's needed Here's a better patch for seed_rng which I'll commit shortly.
(In reply to comment #16) > Created an attachment (id=828) [edit] > provide seed_rng() and document why it's needed > Here's a better patch for seed_rng which I'll commit shortly. OK. Should I be recompiling a patched versin of ssh-rand-helper. Or am I waiting to see a patched seed_rng. BTW thanks for all of your efforts. I will be passing on all this information to our SA's and Management for review because we should be pathch upgrading our version of ssh when appropriate and I think that may be an issue in this problem.
If you want to use the patches you need only apply #760 and the result should build OK on Solaris 8. (If it doesn't, just apply #828 on top). This may or may not help in your situation. For a real fix, apply Sun patch 112438-03 or install prngd.
This is as fixed as we can make it, as mentioned previously the real fix is to install the Solaris /dev/random patch or prngd.
(In reply to comment #19) > This is as fixed as we can make it, as mentioned previously the real fix is to > install the Solaris /dev/random patch or prngd. Thank You.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.