Before I actually implement the small changes needed to allow the location of ssh-rand-helper to be specified in the config file, I'd like to check that in doing so I won't be opening up a huge security hole. My brief reading of the code suggests that in entropy.c:seed_rng() the ssh-rand-helper is run as the original uid (for binaries which were setuid in the first place of course), so I can't spot any obvious holes (but I may not be devious enough). Since almost all the other paths can be overridden in the config (or with -o), and the config file location can also be controlled from the command line (-F for ssh, -f for sshd), I can't see any good reason why the ssh-rand-helper location can't also be... [ I will then nobble ssh-rand-helper to take the prng_cmds from a user-specified source and I'll have a way to give people a small set of files to install anywhere (with a helper shell script to specify all the paths etc) ] -- Jon Peatfield, DAMTP, Computer Officer, University of Cambridge Telephone: +44 1223 3 37852 Mail: J.S.Peatfield at damtp.cam.ac.uk
Since ssh-keygen does not read (and should not) the sshd_config nor ssh_config files. Adding in that ability to the configuration file is really useless in the larger scheme. I would personally rather seen a nice clearly documented mini-howto or FAQ entry explaning how to setup prng or egd w/ OpenSSL. That way ssh-rand-helper is not ran since OpenSSL can internally sead itself. ssh-rand-helper should be viewed as your last line of defence on a box that lacks kernel entropy devices (read: No root access user installing the ssh client). On Mon, 1 Apr 2002, Jon Peatfield wrote:> Before I actually implement the small changes needed to allow the > location of ssh-rand-helper to be specified in the config file, I'd > like to check that in doing so I won't be opening up a huge security > hole. > > My brief reading of the code suggests that in entropy.c:seed_rng() the > ssh-rand-helper is run as the original uid (for binaries which were > setuid in the first place of course), so I can't spot any obvious > holes (but I may not be devious enough). > > Since almost all the other paths can be overridden in the config (or > with -o), and the config file location can also be controlled from the > command line (-F for ssh, -f for sshd), I can't see any good reason > why the ssh-rand-helper location can't also be... > > [ I will then nobble ssh-rand-helper to take the prng_cmds from a > user-specified source and I'll have a way to give people a small set > of files to install anywhere (with a helper shell script to specify > all the paths etc) ] > > -- > Jon Peatfield, DAMTP, Computer Officer, University of Cambridge > Telephone: +44 1223 3 37852 Mail: J.S.Peatfield at damtp.cam.ac.uk > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >
> ssh-rand-helper should be viewed as your last line of defence on a > box that lacks kernel entropy devices (read: No root access user > installing the ssh client).Exactly. I wish to continue to be able to provide downloads of binaries for use by our users if they visit a random site which doesn't (yet) provide ssh. They won't have root access and will almost certainly be running on machines with no kernel entropy source (well the ones with a local entropy source will be ok anyway). Since we no longer allow any other form of remote access it is now more important that we continue to be able to offer such binaries (we had to suffer several sets of _important_people_ complaining when we blocked telnet access, and the availability of downloadable binaries was about the only thing which calmed them down (though they had to have a new procedure explained to them)). Of course most sites do now supply ssh clients but we can't rely on it when people are at random conferences... -- Jon
<smile> 0.9.7 is not the only release to support self-seeding from non /dev/random sources. 0.9.6 does, but requires prompting. - Ben On Tue, 2 Apr 2002, Markus Friedl wrote:> On Mon, Apr 01, 2002 at 09:22:12PM -0600, Ben Lindstrom wrote: > > PRNGD/EGD is supported by OpenSSL also. Therefor if you teach OpenSSL how > > to talk to PRNGG/EGD ssh-rand-helper is not required. > > we should not depend on openssl 0.9.7 > > it does not even exist :) >
> Maybe (I'm half-awake so I'm not considering all the issues) one > should allow OpenSSH to look for ssh-rand-helper in the user's path. > (Default to fixed location, but a configure option). That will > solve the problem in the generic form, but I'm worried about it > selecting a wrong ssh-rand-helper.The thing which worries me most is that if the user can specify the entropy source they could cause it to be fed something which isn't random at all, and so the seeding of the prngd could be very suspect. Normally this is just the user shooting themself in the foot, but if ssh is setuid and (say) using DSA (which I seem to remember needs a very good entropy source (or am I confusing that with something else)), there may be a leak of bits of the host's private key (e.g. when trying rhostrsa or similar). Of course since ssh-rand-helper (and particularly the entropy gathering commands themselves) run as the user a malicious user might be able to cause them to generate whatever output they want anyway. Of course I may be just completely mis-understanding the issues? In the case I'm interested in ssh won't be setuid so I'd be happy enough for the option to be honoured only if ssh isn't running suid though that seems less clean if it is safe anyway (which is why I asked initially). Now to avoid showing my ignorance further I'll shut up for a bit... -- Jon