Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
sshd at boot takes too long
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Tue Jan 28, 2020 11:48 pm    Post subject: sshd at boot takes too long Reply with quote

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?
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1959
Location: Frankfurt, Germany

PostPosted: Tue Jan 28, 2020 11:51 pm    Post subject: Reply with quote

Please look at: https://forums.gentoo.org/viewtopic-t-1101034.html
Back to top
View user's profile Send private message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Wed Jan 29, 2020 12:48 pm    Post subject: Reply with quote

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..
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1959
Location: Frankfurt, Germany

PostPosted: Wed Jan 29, 2020 12:53 pm    Post subject: Reply with quote

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

Look at the output of
Code:
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.
Back to top
View user's profile Send private message
guitou
Guru
Guru


Joined: 02 Oct 2003
Posts: 444
Location: France

PostPosted: Wed Jan 29, 2020 12:56 pm    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
Gatak
Apprentice
Apprentice


Joined: 04 Jan 2004
Posts: 168

PostPosted: Wed Jan 29, 2020 6:43 pm    Post subject: Reply with quote

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)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44900
Location: 56N 3W

PostPosted: Wed Jan 29, 2020 7:00 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Wed Jan 29, 2020 8:44 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
mike155
Veteran
Veteran


Joined: 17 Sep 2010
Posts: 1959
Location: Frankfurt, Germany

PostPosted: Wed Jan 29, 2020 8:57 pm    Post subject: Reply with quote

Please install haveged AND enable it.
Back to top
View user's profile Send private message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Wed Jan 29, 2020 9:18 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44900
Location: 56N 3W

PostPosted: Wed Jan 29, 2020 9:19 pm    Post subject: Reply with quote

ALF__,

None at all. That's why I said speculation.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Zucca
Veteran
Veteran


Joined: 14 Jun 2007
Posts: 1710
Location: KUUSANKOSKI, Finland

PostPosted: Wed Jan 29, 2020 9:33 pm    Post subject: Reply with quote

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

Code:
ERROR: '--failure' is not an option. Aborting...
Back to top
View user's profile Send private message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Wed Jan 29, 2020 10:43 pm    Post subject: Reply with quote

So haveged solved it. Thank yoiu mike155.

Hopefully someone can shed some more light on this problem though.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 14922

PostPosted: Thu Jan 30, 2020 1:42 am    Post subject: Reply with quote

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:
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.
Back to top
View user's profile Send private message
Gatak
Apprentice
Apprentice


Joined: 04 Jan 2004
Posts: 168

PostPosted: Thu Jan 30, 2020 7:13 am    Post subject: Reply with quote

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

Code:
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.
Back to top
View user's profile Send private message
ALF__
Apprentice
Apprentice


Joined: 30 Nov 2003
Posts: 152

PostPosted: Thu Jan 30, 2020 11:07 pm    Post subject: Reply with quote

Oh i see.
Interesting concept!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum