Running out of entropy in Debian Etch

Once in a while you’d run into a situation where your ssh or dropbear takes forever to establish a connection, often failing altogether. Examination of the logs (auth.log and system.log) quickly points out the problem:

“Warning: Reading the random source seems to have blocked. If you experience problems, you probably need to find a better entropy source.”

Basically, your /dev/random is not generating randomness fast enough to establish an ssh session.The problem seems typical of simple embedded devices like NSLU2.

There are effectively thee solution:

  1. Use a service that does not rely on entropy, or
  2. Install a hardware source of randomness (a private nuke would do nicely) or
  3. Fall back on so-called “unlimited” random source (/dev/urandom) – for the detailed discussion of differences between /dev/random and /dev/urandom look here.

As of version 50.2 Dropbear is built to use /dev/urandom by default. But that version is still a part of testing (Lenny) release, so if you want the safety of regular security updates you can use a little trick instead:

mv /dev/random /dev/chaos
ln -s /dev/urandom /dev/random

Understand this: your system will become somewhat less secure as a result. This is your choice. Do your homework and understand the consequences. You are the only person who cares enough.

Now if you have gone ahead with the little renaming scheme above, you are likely up for a surprise next time you reboot: Oh my, the changes are gone!

What happened is you use udev (udev is what Plug-and-Pray wants to become when it grows up). Every time you reboot your Linux, udev creates the logical devices anew based on your physical configuration. So, for your changes to stick, you have to work with udev a bit:

In your /etc/udev directory create a new file, say “chaos.rules” with the following contents:

# renaming /dev/random to /dev/chaos and creating a link to /dev/urandom
# takes care of insufficient entropy

KERNEL=="random", NAME="chaos"
KERNEL=="urandom", NAME="random"

Now go into /etc/udev/rules.d and create a link to this file:

ln /etc/udev/chaos.rules /etc/udev/rules.d/z80_chaos.rules

z80” will tell udev in which order to process this particular file – feel free to experiment at your own risk.

If everything has gone well, after next reboot you will have

/dev/chaos, /dev/random, and /dev/urandom, where the last two will point at the same device, while “chaos” is the “proper” source of randomness.


About this entry