ssh2 protocol). Performing a DSA signature (which is required for
authentication), entails the use of a 160 bit random number. If an
attacker can predict this number, then they can deduce your *private*
-key and impersonate you.
+key and impersonate you or your hosts.
If you are using the builtin random number support (configure will
-tell you if this is the case), then read this document in its entirety
-and consider disabling ssh2 support (by adding "Protocol 1" to
-sshd_config and ssh_config).
+tell you if this is the case), then read this document in its entirety.
+Alternately, you can use Lutz Jaenicke's PRNGd - a small daemon which
+collects random numbers and makes them available by a socket.
Please also request that your OS vendor provides a kernel-based random
number collector (/dev/random) in future versions of your operating
-systems.
+systems by default.
On to the description...
The portable OpenSSH contains random number collection support for
systems which lack a kernel entropy pool (/dev/random).
-This collector operates by executing the programs listed in
-($etcdir)/ssh_prng_cmds, reading their output and adding it to the
+This collector (as of 3.1 and beyond) comes as an external application
+that allows the local admin to decide on how to implement entropy
+collection.
+
+The default entropy collector operates by executing the programs listed
+in ($etcdir)/ssh_prng_cmds, reading their output and adding it to the
PRNG supplied by OpenSSL (which is hash-based). It also stirs in the
output of several system calls and timings from the execution of the
programs that it runs.
The random number code will also read and save a seed file to
~/.ssh/prng_seed. This contents of this file are added to the random
-number generator at startup.
+number generator at startup. The goal here is to maintain as much
+randomness between sessions as possible.
-This approach presents two problems:
+The default entropy collection code has two main problems:
1. It is slow.
-Executing each program in the list can take a large amount of time,
-especially on slower machines. Additionally some program can take a
-disproportionate time to execute.
+Executing each program in the list can take a large amount of time,
+especially on slower machines. Additionally some program can take a
+disproportionate time to execute.
-This can be tuned by the administrator. To debug the entropy
-collection is great detail, turn on full debugging ("ssh -v -v -v" or
-"sshd -d -d -d"). This will list each program as it is executed, how
-long it took to execute, its exit status and whether and how much data
-it generated. You can the find the culprit programs which are causing
-the real slow-downs.
+Tuning the random helper can be done by running ./ssh-random-helper in
+very verbose mode ("-vvv") and identifying the commands that are taking
+excessive amounts of time or hanging altogher. Any problem commands can
+be modified or removed from ssh_prng_cmds.
-The entropy collector will timeout programs which take too long
+The default entropy collector will timeout programs which take too long
to execute, the actual timeout used can be adjusted with the
--with-entropy-timeout configure option. OpenSSH will not try to
re-execute programs which have not been found, have had a non-zero
To make matters even more complex, some of the commands are reporting
largely the same data as other commands (eg. the various "ps" calls).
+
+How to avoid the default entropy code?
+
+The best way is to read the OpenSSL documentation and recompile OpenSSL
+to use prngd or egd. Some platforms (like earily solaris) have 3rd
+party /dev/random devices that can be also used for this task.
+
+If you are forced to use ssh-rand-helper consider still downloading
+prngd/egd and configure OpenSSH using --with-prngd-port=xx or
+--with-prngd-socket=xx (refer to INSTALL for more information).
+
+$Id$
andersk / openssh.git / blobdiff