PuTTYgen, being a Windows application, assumes that a mouse is connected and prompts the user to move the mouse to generate entropy during key creation.
By comparison, ssh-keygen documents the SSH_USE_STRONG_RNG environment variable -- but then recommends against its use (!) since it can cause key generation "to be blocked until enough entropy is available".
It's not consumable, but it can be in short supply right after boot. So /dev/random should block until there's sufficient entropy, but never after that.
If I recall correctly, at one point, the network interface was used as a source of entropy. Then someone demonstrated that sending the right sequence of network packets to a machine would let you control the key that got generated. So they removed it.
Then folks discovered -- in production -- that some cloud computing environments just don't get any other new entropy after boot, and so instances would hang on generating SSH host keys.
Some folks went to /dev/urandom. Other folks decided to seed instances with entropy from another computer (with fancy names like "cloud entropy service"). And then someone had to decide how that machine gets entropy (like plugging in an FM radio into the mic jack).
The kernel knows how many bytes you've fed into it. But it has no fundamentally sound way of computing a lower bound on how much entropy those bytes contained; the best approaches involve calculating an upper bound and then say "well hopefully it's at least X% of this".
By comparison, ssh-keygen documents the SSH_USE_STRONG_RNG environment variable -- but then recommends against its use (!) since it can cause key generation "to be blocked until enough entropy is available".