hi!
Dropbear 0.52 should be using /dev/urandom, which AFAIK
won't block? Unless the behaviour of recent kernels has
changed...
If Dropbear is blocking on the random device it should log
something - could you check the auth logs?
the problem actually didn't occur to myself, my role is just a
nag-target/-relay here... ;)
i'm not sure why, but on several systems (and that includes fat multicore amd64
systems as well as armel devices) where i'm using dropbear in initramfs myself,
this hasn't been an issue.
but i got reports that this happens. once i actually saw a system 'hanging' at
boot, but didn't have a chance to do some debugging, sadly.
i.e. i don't have logs and not even a system where i know i could reproduce the
problem... :(
to check the behaviour of dropbear when there's no(t enough) data coming from
/dev/urandom i simply made it a symlink to some character device that doesn't
output anything. this resulted in dropbear blocking before forking into
background. i know that urandom shouldn't block. but it seems that it can
happen (maybe on those systems urandom is just a symlink to random or something
like that - dunno).
i guess in any case - even if a blocking /dev/urandom were itself an error -
that's probably worth to be addressed? then again - if a blocking random device
gets logged, that sounds to me like it already is handled??
regards,
Chris
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
