# sshd at boot takes too long

## ALF__

For some reason starting sshd at boot takes a long while. It sits there for maybe a minute.

Removing it from boot solves it. And starting it manually with /etc/init.d/sshd start goes very fast.

No errors from what i can see.

Any ideas?

----------

## mike155

Please look at: https://forums.gentoo.org/viewtopic-t-1101034.html

----------

## ALF__

 *mike155 wrote:*   

> Please look at: https://forums.gentoo.org/viewtopic-t-1101034.html

 

Thanks for your response, but I'm not sure this is applicable in my case.

As stated, this only happens during boot. It does not take this long when deactivating auto start and staring it manually..

----------

## mike155

 *Quote:*   

> Thanks for your response, but I'm not sure this is applicable in my case. 

 

Look at the output of

```
dmesg | grep "crng init done"
```

It tells you how many seconds it took before your random number generator was available. If you get a huge number, you're probably affected. If you get a small number, it's probably something else.

----------

## guitou

Hi.

Mike's suggestion looks quite right, regarding the symptoms you gave: "sshd being slow to start at boot" might well be related to a matter of entropy (random number generation initialization)

++

Gi)

----------

## Gatak

You can add RANDOM_TRUST_CPU=Y in your kernel config. You should know there is some risk that this could make your crng deterministic. 

In menuconfig go to Device Drivers, then select: [*] Trust the CPU manufacturer to initialize Linux's CRNG

Then, if all is well you should see this being active in dmesg:

[    0.130084] random: crng done (trusting CPU's manufacturer)

----------

## NeddySeagoon

Gatak,

Why would you trust a CPU vendor?

Todays CPUs are the hardware implementation of software and we all agree that software is buggy.

Think Spectre, Meltdown and other CPU bugs.

There is a long history of attempting to play these things down.

Then there is the speculation that the NSA may have had a hand in crippling the CPU hardware random number generators.

----------

## ALF__

Thanks everyone,

Yep, its the RNG that takes 45 seconds.. At first i just saw the init with green OK a couple of lines up, and thought it just had to do with the SSHD.

So i pulled in jitterentropy and added that in my kernel, still the same though.

Have no experience with the RNG at all, never had a problem from that in all my years, so i probably activated it wrong?

NeddySeagoon,

That sounds very interesting, do you have any reference to the hardware crippling?

----------

## mike155

Please install haveged AND enable it.

----------

## ALF__

 *mike155 wrote:*   

> Please install haveged AND enable it.

 

I went blindly with the info in the linked thread and used jitterentropy since the other one seem to be obsolete?

Will redo it with haveged instead then.

Also, does anyone have any info why this is suddenly a problem? Is it a problem on the sshd side, or is it some kernel problem?

----------

## NeddySeagoon

ALF__,

None at all. That's why I said speculation.

----------

## Zucca

Ok. What's the difference between these then? jitterentropy and haveged?

----------

## ALF__

So haveged solved it. Thank yoiu mike155.

Hopefully someone can shed some more light on this problem though.

----------

## Hu

The crippling to which Neddy alludes is, as he says, speculation.  If it had happened, the most likely form of it would be that the hardware random number generator would generate output that appears "random enough" on conventional tests that the public would accept it as "unpredictable high quality randomness," but there would be some pattern to it that, if you knew the algorithm, would let you predict its behavior.  As a simple example, suppose the "random" generator was implemented by something like the following pseudo-code:

```
uint64_t counter;

void power_on() {

   counter = 0;

}

int rdrand() {

   char buf[16];

   buf[0] = (counter >> 0) & 0xff;

   buf[1] = (counter >> 8) & 0xff;

   buf[2] = (counter >> 16) & 0xff;

   buf[3] = (counter >> 24) & 0xff;

   buf[4] = (counter >> 32) & 0xff;

   buf[5] = (counter >> 40) & 0xff;

   buf[6] = (counter >> 48) & 0xff;

   buf[7] = (counter >> 56) & 0xff;

   buf[8] = 0;

   buf[9] = 0;

   buf[10] = 0;

   buf[11] = 0;

   buf[12] = 0;

   buf[13] = 0;

   buf[14] = 0;

   buf[15] = 0;

   ++ counter;

   aes256_encrypt(buf, nsa_secret_key);

   return

      ((unsigned) buf[0]) << 0) |

      ((unsigned) buf[1]) << 8) |

      ((unsigned) buf[2]) << 16) |

      ((unsigned) buf[3]) << 24);

}
```

Assume almost no one knows this is the real implementation (and that those who do know will keep it secret), and that the nsa_secret_key is known only to the same set of people.  AES encrypting even a simple counter value can produce decent looking randomness, especially if, as here, only part of the result is returned.  However, if someone knows this is the algorithm, and can observe one of your "random" numbers (such as in a nonce that is required to be sent in the clear), then he can successively encrypt a variety of counter values until he gets that observed number.  He now knows how many random numbers you generated since power-on, and can predict them forward and backward.

A truly sneaky implementation would be more clever than I showed.  Among other things, it should have a more complicated initialization system, so that repeatedly testing the same system doesn't produce obviously non-random results.

The only way to be sure this has not happened is to decompile the CPU hardware and account for every non-trivial aspect of how it produces random numbers.  That requires special hardware and expertise that few people possess.

----------

## Gatak

Thanks @Hu for a very good explanation.

There is another way, and that is to have SSHD not wait for entropy. This would mean that those risks you talk about would be during boot, when sshd was loaded but before prober crng init was done?

/etc/init.d/sshd

```
depend() {

    # Entropy can be used by ssh-keygen, among other things, but

    # is not strictly required (bug 470020).

    use logger dns entropy

```

We can remove the "entropy" option here.

Again, I am not saying you should. You all need to assess if these are risks for you. A risk is defined as  likelyhood x consequence.

----------

## ALF__

Oh i see. 

Interesting concept!

----------

