# Generating entropy on a headless diskless machine

## KShots

I need to generate entropy on a headless, diskless machine. Attaching a keyboard or mouse is not an option.

Normally, entropy is generated by simply typing into a keyboard or initiating disk activity, or mousing around the screen.

In my case, I need entropy to be generated because without it cupsd will hang - it does a select on urandom, which will block until entropy is generated for the generation of an ssl key.

For example, currently I have an entropy of 2 bytes:

```
mythtv@madusa /etc/init.d $ sudo sysctl kernel.random.entropy_avail

Password:

kernel.random.entropy_avail = 2
```

After running find /:

```
mythtv@madusa /etc/init.d $ sudo sysctl kernel.random.entropy_avail

Password:

kernel.random.entropy_avail = 2
```

Any ideas? Thanks

----------

## depontius

This may not be a solution for you, since the machine may be "fixed," but some machines include a hardware random number generator, either in the chipset (some Intel chipsets) or in the CPU (some Via CPUs) itself. There are also some aftermarket devices here: http://www.true-random.com/  But watch out for the cost. You might also be able to find some references for a DIY hardware rng using diode noise.

----------

## KShots

Yeah, I'd looked closely at that when building a kernel... unfortunately, this machine does not have a hardware random number generator. I'd also find it rather annoying to have to plug in an external hardware random number generator just to get my print server working. Also, this machine has 0 slots available - it's a 1U rack-mounted machine with 2 PCI cards inserted (TV capture cards, actually). These naturally generate a lot of random noise from the analog signal they capture, but I doubt anyone's written a random number generator to take advantage of that.

----------

## depontius

Now that I reread your initial post and response, I have a different recommendation.

Plug in the silly keyboard/mouse.

They don't need to stay there, they're only needed the first time cupsd runs, in order to generate the ssl certificate. Thereafter they won't be needed again. Plug in the keyboard/mouse, get the system fully started this one time, then unplug them. You'll never need them again, at least not until some other package decides it needs an ssl certificate, and only then for the first startup.

By the way, other packages such as ssh have the same requirement. It just depends on whether it's been hidden in emerge or in first-run.

But for ongoing operation, none of these packages need keyboard/mouse.

----------

## KShots

The reason I was avoiding the keyboard / mouse solution is because I may well start implementing machines in distant locations that are headless and diskless also. I was just hoping there was a better solution - this just seems like a kind of hack.

As far as ssh goes, I'm not running into problems running an SSH server (at all). I'd also noted I can generate SSL keys and certificates manually, but from what I've read they don't use the entropy anymore.

----------

## depontius

But are you going to install headless? 

After all, the first startup with it's attendant CUPS ssl certificate creation could be considered part of installation. I believe ssh builds its ssl certs during the emerge - it does have them somewhere - I've looked while bringing up a machine and seen the creation step, though I can't remember exactly when/where.

Or for that matter, if you really are installing headless, you could make sure CUPS is disabled on first boot. Create the ssl certs on a machine with plenty of entropy, and scp them to the headless machine, then add CUPS to the startup. It might take a little hacking to see exactly what CUPS is looking for, so you can use the manual/remote solution.

----------

## KShots

Normally, I install by starting /etc/init.d/sshd as the first thing I do, followed by inserting a root password and walking off to another machine to finish the install. SSH generates its keys on startup if it notices it doesn't have any. This means the first time /etc/init.d/sshd is run, generally. Oddly enough, on first bootup it had no problem generating keys without entropy.

I had also tried generating my own SSL keys. I even used the same machine to generate them (successfully). However, I couldn't figure out how to cause CUPS to use those keys (using apache2-like terminology in the config file to use the keys just caused unrecognized commands in the file). OpenSSL itself doesn't need entropy to generate keys, but cupsd does.

Anyways, for this particular setup, I did bang out a keyboard and fill a temporary file with 3k of random keyboard tappings, and restart the cups server... and it worked.

EDIT: I should also note that cupsd does not hang on startup, it hangs when someone goes to the administration pages on host:631. Letting it start on boot is not a problem.

I'd mark this as solved because I'm now in a working state, but the problem in the subject line is still unsolved - I'm just curious at this point on how to do such a thing.

----------

## KShots

Well... I'm back to square one.

I rebooted the machine, and I'm out of entropy again. How do I fix this?

----------

## styrmis

One of the first hits on Google was this: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt

[quote=LFS]

- Audio/Video entropy daemon:

http://www.vanheusden.com/aed/

http://www.vanheusden.com/ved/

This describes two daemons which use either the static noise from the

system audio, or the video frames from a video4linux device. These devices

have a never ending supply of randomness created by thermal fluctuation and

electric fields on the devices.

[/quote]

And much simpler, network traffic causes generation of entropy according to the above link.Last edited by styrmis on Wed Feb 14, 2007 1:26 pm; edited 1 time in total

----------

## KShots

 *styrmis wrote:*   

> One of the first hits on Google was this: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt
> 
>  *LFS wrote:*   
> 
> - Audio/Video entropy daemon:
> ...

 Now, that's exactly the sort of thing I'm looking for! Thanks! *styrmis wrote:*   

> And much simpler, network traffic causes generation of entropy according to the above link.

 If that were true, then you'd think on a network-booting system running mythtv backend I'd have more than 4 bytes of entropy.

EDIT: I spoke too soon... the video entropy daemon doesn't work:

```
mythtv@madusa ~ $ dmesg | grep video

Boot video device is 0000:00:0c.0

Linux video capture interface: v2.00

ivtv0: Registered device video0 for encoder MPEG

ivtv0: Registered device video32 for encoder YUV

ivtv0: Registered device video24 for encoder PCM audio

ivtv1: Registered device video1 for encoder MPEG

ivtv1: Registered device video33 for encoder YUV

ivtv1: Registered device video25 for encoder PCM audio
```

```
mythtv@madusa ~ $ sudo /usr/sbin/video-entropyd /dev/video32

video_entropyd v0.7, by folkert@vanheusden.com (www.vanheusden.com)

VIDIOCGMBUF: Invalid argument

Floating point exception
```

... and trying MPEG gives the same result. This one's a non-starter. The audio entropy daemon won't work as there is no audio device on this machine.

----------

