I'm running into this since I prefer my headless slug start the ssh server as early in the boot process as possible -- which increases the chances of not enough entropy.
I don't understand this comment from #310732: > A solution could be to have dropbear first check /dev/random, and if > it blocks, to fall back to /dev/urandom. Avoiding /dev/random blocking is exactly what /dev/urandom is designed for. There is no need to read from /dev/random first and try to detect it blocking; a read from /dev/urandom will return full-quality random data same as /dev/random, if it's available. It's worth noting that openssh uses /dev/urandom. Using /dev/random is appropriate for things like gnupg key generation that generate long-lived keys and require absolute best-effort randomness, but it doesn't seem warrented for a (semi-)transient ssh session key, especially when the result is that the vital ssh service can't be relied on because the daemon may have hung during boot. It's perhaps also noteworthy that OpenWRT's dropbear is built to use /dev/urandom. I imagine that anyone using it in production will do the same: the entropy issues are absolutely crippling. -- see shy jo
signature.asc
Description: Digital signature
