We are using beaglebone based custom board.
In one of the init script we are generating ssh keys but it takes around 7 seconds to generate the ssh-keys. How do we speedup the process of generating ssh keys ?
From ssh tutorial we came to know that ssh-keygen waits for enough entropy to generate the ssh keys.
How do we create enough entropy before generating ssh keys ?
Any suggestions/pointer will help
I am not sure if this will work on a Beaglebone, but it does work on virtual machines without a proper random source, so your mileage may vary
On Linux, /dev/random uses the entropy pool maintained by the kernel to generate randomness. There are two ways to speed up the entropy generation:
dd if=/dev/hda1 of=/dev/null (replace hda1 with your disk)/dev/random, like dd if=/dev/hda1 of=/dev/random. However, this decreases the randomness in the pool. It might be better to use an audio source to write to /dev/random.
dd seems identical to the first one...
Jun 6, 2014 at 13:11
dd for different devices. Keep in mind that OpenSSL also does a lot of crypto, so you might also want to check your CPU usage. If you're running at 100% CPU, there's not much more you can do to speed up key generation. If you still need more entropy, you might want to look into a hardware random number generator, they come as USB sticks and you should be able to find one for under EUR 50.
From your comment,
when i generate the key i get "+--[RSA1 2048]----+" so i suppose its 2048 right ?
it sounds like your boot process generates SSHv1 keys in addition to SSHv2. So you end up generating at least two RSA keys (and probably a DSA key and an ECDSA key).
If you turn off SSHv1 key generation, it might cut the time by half. (Version 1 of the SSH protocol has some serious problems and should never be used, anyway.)
I have a history of necrobumping posts (hi, Google/DDG/Bing(?!) users!), but I'd avoid using the dd trick. One source of entropy generation is not so hot when you can use something specifically designed for this!
A couple things cause slow key, DH param, etc. generation.
The first is hardware. The CPU on a Beaglebone Black, at the time of writing this, is (per their site) an "Arm Cortex-A8, 3D Graphics, PRU-ICSS". Now, I know you said you're using a custom Beaglebone-based board, but I digress - probably the same CPU (or an earlier run, given that I'm answering a 4.5-year-old question). Not the best for heavy crypto, but you make do with what you have. You could see if there's perhaps a peripheral for the board that uses a HRNG (Hardware Random Number Generator). An HNRG would vastly speed things up.
The second, as hinted at by other answers, is the available entropy. Key generation uses /dev/random instead of /dev/u(nblocking)random. This is a good thing. /dev/random generates much better randomness (at the price of, you guessed it, blocking). This means that the system will wait for more entropy to become available and then generate the randomness from that. Which, if you're on a headless server, and a headless server that is on limited hardware at that, and on a headless server with limited hardware with no HNRG, and yeah. This will take a long time. Idle servers just don't generate enough "digital noise" to be able to generate entropy quickly!
So what is a security-conscious lad or lass to do?
Why, have good entropy, of course! haveged is a daemon that runs the HAVEGE algorithm which creates that digital noise using some clever maths and is widely recommended for this sort of thing. It should be very easily installed; I'm not aware of any modern distro release that doesn't have it in its repos.
