On systems that don't have a fast source of entropy such as /dev/random or prngd, startup up of ssh takes a long time because it runs a lot of external programs. I have made a patch to add an option to intialize the pseudo-random number generator from a saved seed file rather than running all the external programs, which I will add as an attachment.
Created attachment 4 [details] added proposed patch
I don't like this - you could easily end up in a situation where you end up using essentially the same seed over and over again.
No, that's not true, because every startup still adds small amounts of easily gathered entropy. You could argue that that means people could guess all the possibilities and try them all, but they can't because they do not know the contents of the seed file which was originally generated from a large amount of entropy. The only added risk is that somebody may get hold of the seed file, but if the ~/.ssh directory is not secured someone could easily break in anyway so I maintain that it doesn't add any more overall risk. There is no way for someone to guess the contents of the seed file by examining network traffic because the psuedo-random number generation process is not reversible. As an added protection, the seed file is re-written with additional entropy mixed in each time ssh is run. You don't have to rely on just my arguments, either: the SSH 1.2.* series did this and there was never any CERT advisories nor complaints from crypto experts about it, and pointing out SSH weaknesses have brought fame to many of them so I'm sure that if there was a weakness here you would have heard about it. Also, GnuPG does essentially the same thing on systems that don't have /dev/random.
This is redundant now. You can implement whatever local policy you like using shell script wrappers around the new ssh-rand-helper in -current CVS
Mass change of RESOLVED bugs to CLOSED