how to speedup ssh-keygen
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
ssh openssh ssh-keys
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
|
show 1 more comment
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
ssh openssh ssh-keys
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
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
|
show 1 more comment
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
ssh openssh ssh-keys
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
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
ssh openssh ssh-keys
ssh openssh ssh-keys
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
asked Jun 6 '14 at 12:33
AnkurTankAnkurTank
2051312
2051312
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
|
show 1 more comment
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
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
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
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
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
@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
@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
|
show 1 more comment
3 Answers
3
active
oldest
votes
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(replacehda1with your disk) - Write extra data into
/dev/random, likedd 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.
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
Nice answer, but the secondddseems 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 ofddfor 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
|
show 1 more comment
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.)
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
: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
add a comment |
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.
answered Jan 13 at 16:22
brent sanerbrent saner
993
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f764446%2fhow-to-speedup-ssh-keygen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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(replacehda1with your disk) - Write extra data into
/dev/random, likedd 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.
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
Nice answer, but the secondddseems 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 ofddfor 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
|
show 1 more comment
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(replacehda1with your disk) - Write extra data into
/dev/random, likedd 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.
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
Nice answer, but the secondddseems 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 ofddfor 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
|
show 1 more comment
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(replacehda1with your disk) - Write extra data into
/dev/random, likedd 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.
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
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(replacehda1with your disk) - Write extra data into
/dev/random, likedd 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.
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
edited Jun 6 '14 at 13:20
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
answered Jun 6 '14 at 12:54
mtakmtak
11.1k23353
11.1k23353
Nice answer, but the secondddseems 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 ofddfor 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
|
show 1 more comment
Nice answer, but the secondddseems 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 ofddfor 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
Nice answer, but the second
dd seems identical to the first one...– MariusMatutiae
Jun 6 '14 at 13:11
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
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
@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
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
@AnkurTank Did you get positive results with this method?
– mtak
Jun 12 '14 at 9:13
|
show 1 more comment
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.)
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
: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
add a comment |
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.)
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
: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
add a comment |
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.)
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
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.)
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
answered Jun 6 '14 at 13:51
grawitygrawity
236k37500556
236k37500556
: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
add a comment |
: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
: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
: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
add a comment |
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.
answered Jan 13 at 16:22
brent sanerbrent saner
993
add a comment |
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.
answered Jan 13 at 16:22
brent sanerbrent saner
993
add a comment |
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.
answered Jan 13 at 16:22
brent sanerbrent saner
993
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.
answered Jan 13 at 16:22
brent sanerbrent saner
993
edited Jan 26 at 21:46
answered Jan 13 at 16:22
brent sanerbrent saner
993
answered Jan 13 at 16:22
brent sanerbrent saner
993
answered Jan 13 at 16:22
brent sanerbrent saner
993
993
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f764446%2fhow-to-speedup-ssh-keygen%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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