On 04/30/2014 01:08 PM, Lennart Poettering wrote:
On Tue, 29.04.14 20:43, Florian Weimer ([email protected]) 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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
