2

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

  • How large is the key itself ( bits )? You might not be able to speed it up depending on the size of the key. – Ramhound Jun 6 '14 at 12:45
  • iirc pressing keys and moving mouse helps – LatinSuD Jun 6 '14 at 12:46
  • How are you generating the entropy exactly? Are you doing it through hardware or through softwarE? – Ramhound Jun 6 '14 at 12:51
  • @Ramhound: i think its 2048bits, we are not generating entropy by hardware/software explicitly. – AnkurTank Jun 6 '14 at 12:57
  • @AnkurTank - Go verify what it is exactly then update the question. You need to generate entropy otherwise its very possible the key you generate won't be secure. – Ramhound Jun 6 '14 at 13:01
3

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:

  • Generate lots of IO, you can use dd if=/dev/hda1 of=/dev/null (replace hda1 with your disk)
  • Write extra data into /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.
  • Nice answer, but the second dd seems identical to the first one... – MariusMatutiae Jun 6 '14 at 13:11
  • Typo :) I updated my answer. – mtak Jun 6 '14 at 13:21
  • @mtak:thank you for answer, I think randomness is the key right? instead of /dev/hda1 i will test with /dev/mtd1. meanwhile we don't have audio source in board, is there other alternative to increase entropy? – AnkurTank Jun 7 '14 at 2:18
  • I am not sure, but reading from any (hardware) device should give you more entropy. You could try starting more sessions of 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. – mtak Jun 7 '14 at 7:53
  • @AnkurTank Did you get positive results with this method? – mtak Jun 12 '14 at 9:13
0

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.)

  • :Thank you for answer, yes you are right, we are generting rsa1, dsa,rsa,ecdsa keys. I will have to ask seniors and check if they really need to generate rsa1 key or not. – AnkurTank Jun 7 '14 at 2:20
-1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.