[systemd-devel] Delaying (SSH) key generation until the urandom pool is initialized

[Florian Weimer]

On 04/30/2014 01:08 PM, Lennart Poettering wrote:
> On Tue, 29.04.14 20:43, Florian Weimer (fweimer at redhat.com) wrote:
>
>> The message at <https://mail.gnome.org/archives/ostree-list/2014-February/msg00010.html>
>> contains two boot traces from virtual machines which show that the
>> SSH key is generated before the kernel pool is sufficiently seeded.
>
> Are you saying ssh reads from /dev/urandom rather than /dev/random, but
> it should be reading from the latter?

No, that's not what I wrote.

Using /dev/urandom for key generation is fine once its pool is seeded. 
Using existing key generation algorithms with /dev/random instead does 
not work because they consume too much entropy and can block for 
significantly more time than just a few minutes.

> WHat does that have to do with systemd?

It seems related to boot ordering, device availability, kernel event 
signaling and so on (although we have little of that at present).

In particular, what I want is that a one-shot service for key generation 
only blocks on pool seeding when it actually needs to run (because the 
keys do not exist yet).  From a support perspective, it seems better to 
do the waiting outside the one-shot service, so that systemd tools can 
be used to examine what is causing the delay.

>> Would it be possible using socket activation to create the listening
>> socket for SSH, but block the actual service startup until the keys
>> have been generated after sufficient entropy became available?
>>
>> What would you need on the kernel side to implement the waiting?
>> (Textual comparison of a log message is only good for a prototype.)
>
> THis already exists. It's called /dev/random...

No, /dev/random can (and will) block long after booting.

-- 
Florian Weimer / Red Hat Product Security Team