Hi,
When you let OpenSSH use the egd protocol directly it will get its entropy from an egd daemon. Otherwise it uses /dev/random. When you use ekeyd-egd-linux then you feed the entropy from the egd daemon to the pool used for /dev/random. That way you are not completely dependent on the egd daemon, and other applications that need entropy benefit from the better-filled pool.
And yes, I run ekeyd-egd-linux on many VMs 
Sander
Haveged, every time.
Linux 3.7 will be getting some improvements in terms of entropy collection, to
the point that it may well render haveged unnecessary.
Generally speaking I find that it's VMs that prove to suffer from low entropy
(and thus benefit greatly from haveged)
Regards,
Oliver
You would then be interested in http://hundun.ae7.st. Server I setup just a
week or so ago doing this very thing. However, if using a server's random
data, it's important you mix it into your /dev/random device, rather than
using the data directly. After all, how can you trust the admin, that he's
not keeping track of which client is receiving which data?
It's interesting... though Lava lamps require heat to work, so not
necessarily energy efficient. In theory, you shouldn't really need
the lava lamp part. Just the digital camera part.. operate at a
high ISO, say ISO 3000, dark background, and manual shutter and
aperature controls, configured to achieve exposure with minimal light
(E.g. a lowest possible usable exposure at the highest speed you can
get), analyze, and discard the value of any pixels that statistically
show as "hot" or "correlated" and capture the inherent CCD sensor
noise due to unpredictability of electrons, which you maximized,
without having to have any movement in the scene.
You didn't read the whole page. On the right side:
our LavaRnd^tm
Spelled *LavaRnd*, mixed case with 2 a's
Reference implementation uses lens-capped digital cameras to produce random numbers.
Directly produces cryptographically sound <http://www.lavarnd.org/faq/crypto_sound.html> random numbers. A single camera image frame can typically produce between 340 and 1420 bytes bytes of random numbers.
jc