On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes:> On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > > > It would (IMHO) be useful if there were a way to optionally configure > > that code to fall back to the internal entropy gathering routines in the > > event that EGD was not available; as it is, the routines simply fail if > > EGD is unavailable at the time the ssh daemon or client is invoked. > > > > Is this a feature the OpenSSH Portability Team would consider > > worthwhile? > > Probably not - in fact we want to deprecate the built in entropy > collection in favor of the use of a daemon or subprocess.I can understand that desire, and I don't mean to be argumentative, but I'm looking at it from the standpoint of a sysadmin. Right now, my systems use the internal entropy gathering. I _want_ to move to PRNGD. However, I don't want my systems to stop working entirely if PRNGD isn't running or if its socket gets clobbered. For instance, I need the ability to run ssh *clients* from the console in single-user mode, before PRNGD has started up. By not having an option to fall back, it's making it more difficult to justify the case for installing PRNGD, because functionality takes precedence over efficiency. I don't see a downside to having a configure-time option (off by default) like "--with-entropy-fallback" to use the built-in code if (and only if) the daemon were unreachable, unless the OpenSSH Portability Team considers it better to fail completely than to use the deprecated code. Am I missing something? I'd be willing to code the change. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican
On Fri, Sep 28, 2001 at 10:13:50AM -0400, Dan Astoorian wrote:> On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes: > > On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > > > > > > It would (IMHO) be useful if there were a way to optionally configure > > > that code to fall back to the internal entropy gathering routines in the > > > event that EGD was not available; as it is, the routines simply fail if > > > EGD is unavailable at the time the ssh daemon or client is invoked. > > > > > > Is this a feature the OpenSSH Portability Team would consider > > > worthwhile? > > > > Probably not - in fact we want to deprecate the built in entropy > > collection in favor of the use of a daemon or subprocess. > > I can understand that desire, and I don't mean to be argumentative, but > I'm looking at it from the standpoint of a sysadmin. Right now, my > systems use the internal entropy gathering. I _want_ to move to PRNGD. > However, I don't want my systems to stop working entirely if PRNGD isn't > running or if its socket gets clobbered. For instance, I need the > ability to run ssh *clients* from the console in single-user mode, > before PRNGD has started up. > > By not having an option to fall back, it's making it more difficult to > justify the case for installing PRNGD, because functionality takes > precedence over efficiency. > > I don't see a downside to having a configure-time option (off by > default) like "--with-entropy-fallback" to use the built-in code if (and > only if) the daemon were unreachable, unless the OpenSSH Portability > Team considers it better to fail completely than to use the deprecated > code. > > Am I missing something? > > I'd be willing to code the change.I submitted a patch to allow all sources of entropy to be selected at runtime. Thread begins at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99193668118573&w=2 It works by allowing you to specify multiple sources of entropy at configure time, and choosing between them all at runtime. I haven't updated it to 2.9.9p2 yet, I'll post it again when I do. The last response from Ben was that it probably wouldn't get in until after 3.0. - Dave Dykstra
On Fri, 28 Sep 2001, Dan Astoorian wrote:> On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes: > > On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > Is this a feature the OpenSSH Portability Team would consider > > > worthwhile? > > > > Probably not - in fact we want to deprecate the built in entropy > > collection in favor of the use of a daemon or subprocess. > > I can understand that desire, and I don't mean to be argumentative, but > I'm looking at it from the standpoint of a sysadmin. Right now, my > systems use the internal entropy gathering. I _want_ to move to PRNGD. > However, I don't want my systems to stop working entirely if PRNGD isn't > running or if its socket gets clobbered. For instance, I need the > ability to run ssh *clients* from the console in single-user mode, > before PRNGD has started up.In these cases the built-in prng is just about useless as most of its sources of entropy assume an active system. I would like to replace the built in prng with a choice of /dev/random (or equiv), EGD/PRNGd and a new option to execute a subprocess which dumps entropy to stdout. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer
On Fri, 05 Oct 2001 04:09:18 EDT, Damien Miller writes:> > Unfortunately, sshd generally needs its entropy when it starts up, which > > is typically just after boot time, when not that much entropy is > > available from _any_ local source. > > That is why the portable OpenSSH entropy code stores a seed file > between invocations.Good point. So, if "fallback to internal entropy" were configured, then the seed file should be written even when using other sources of entropy when they're available. Doing so would actually improve the entropy in the seed file most of the time. (If sshd is started only at boot time, and root never runs the ssh client, how good is the entropy in /.ssh/prng_seed? I know the seed file gets rewritten every time a fork()'d sshd exits, but still....)> > (Suppose your host has crashed, and there's filesystem damage. You're in > > single-user mode, and your root filesystem is read-only pending an fsck. > > Your socket was /etc/entropy, so prngd can't unlink it to start up > > again. You're missing a file that you need for the recovery procedure, > > but you can't scp it over to /tmp because the ssh client won't run while > > /etc/entropy exists and the daemon isn't up. > > I'd rather not risk compromising the security of the entire system > because of pathological corner cases. If we put an option in to use > insecure entropy sources, then people will just use it anyway.Well, while I can't argue that a system that can't be booted isn't technically more secure than one using SSH with poor entropy, I'd find that of little comfort when my phone is ringing off the hook because the mail server is down. If the seed file is written even when the internal entropy is not in use, I don't see how "use EGD when available, fall back to internal entropy generation" is less secure than "always use the internal entropy generation" on hosts that don't have it available. Even if it were less secure, I think that requiring the sysadmin to explicitly compile in the support to fall back to the builtin code, _plus_ requiring the user to confirm that they want to connect despite the poor source of entropy, is a sufficient barrier that admins won't generally do it unless they've weighed the security considerations against the availability requirements. OpenSSH still has the ability to enable RhostsAuthentication, and you don't even have to explicitly configure that option in at compile time, if I'm not mistaken. And for compatability reasons, I believe the client still supports "cipher none" (though the server, rightly, does not). I can't imagine that allowing ssh to be forced to proceed with poor entropy is a bigger risk than those. [OpenSSL automagically seeds itself from /dev/urandom, has EGD support:]> The difficulty lies in knowing whether OpenSSL has been compiled with > such support and whether or not it is working.With respect to those sources which OpenSSL uses automatically, RAND_status() solves that problem. Entropy.c should probably check RAND_status() before opening RANDOM_POOL or connecting to EGD. OpenSSL uses /dev/urandom transparently, and when OpenSSL 0.9.7 comes out it will (I'm told) try to connect to EGD, also transparently. If OpenSSH also collects entropy from those sources when it doesn't need to, it will deplete the entropy pool faster than necessary. (My apologies if I've misread entropy.c and the code already does this.) I'm not clear enough on the distinction between init_rng() and seed_rng() to know whether it would be reasonable to check RAND_status() from init_rng(), so that the internal code wouldn't be called if OpenSSL could find enough entropy on its own. Also: currently, OpenSSH compiles in the internal code if it cannot find another source of entropy. You could probably make it possible to configure OpenSSH with *no* sources of entropy, i.e., have OpenSSH rely entirely on OpenSSL to collect it, if you wanted to. (I realize you hope to deprecate the internal code entirely; I think we can substitute "call an external program to collect entropy" for "call the internal entropy collection code" throughout, and the design issues don't change much.) Let me know if there's anything I can do to contribute, code-wise. I'd be willing to work on reorganizing the internal entropy collection code into an external program and rewriting entropy.c to use it, but I don't want to interfere with existing efforts. Speaking of interfering with existing efforts, I do hope I'm actually raising relevant design issues, and not merely distracting and irritating you with this discussion.... -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican