On Mon, 2003-03-31 at 20:18, Vincent Danen wrote: > On Sun Mar 30, 2003 at 09:35:58AM -0800, James Sparenberg wrote: > > > > > OK I see what happened... > > > > The package created both an xinetd and standalone version of the run > > > > scripts. The standalone version functions correctly. When started via > > > > xinetd it does not create the keys. > > > > > > Wonderful... I love it when people change my packages without informing me. > > > Why ssh is running out of xinetd is beyond me. > > > > > > Thierry, is there a reason why we want/need openssh to run out of xinetd? > > > That just seems silly to me. > > > > > > Honestly I didn't think it was possible... hmmmm but shure as shoot. > > /etc/xinetd.d/sshd-xinetd does exist. I thought the d in sshd meant > > daemon..... oh never mind. The interesting thing is is that the server > > listed is sshd with a -i option. > > > > >From the man page. > > > > -i Specifies that sshd is being run from inetd. sshd is > > normally not run from inetd because it needs to generate > > the server key before it can respond to the client, and > > this may take tens of seconds. Clients would have to wait > > too long if the key was regenerated every time. However, > > with small key sizes (e.g., 512) using sshd from inetd may > > be feasible. > > > > > > >From what I can see it should regen the key everytime it runs and only > > when it runs. So not having a key on the box would be normal. Wouldn't > > this really muck up RSA authentication and key checking? > > No. The key isn't regenerated each time. That would play all kinds of > havoc with authentication and would render known_hosts virtually useless. I > believe this is for some sort of hash that sshd uses internally for the > keys... it isn't the actual keyfile that is regenerated each time. > > In fact, because of this, I don't understand why Thierry made it runable > from xinetd. Sure, it's possible, but it's so inefficient to make it pretty > much worthless. > > As soon as I found out why he did it, I plan to take it out... no one should > run sshd from xinetd. The default keysize we use is 768 bits, and the > regeneration is done every 3600 seconds. Note this is only for RSA1 keys. > The key is regenerated to prevent decryption of captured sessions. > > So the problem isn't this -i option or anything. The problem is that on a > new install without any previous keys, if you decide to run from xinetd, you > have to manually create your keys since you're not using the initscript. > > All the way around, this xinetd business is not really good and I'm itching > to rip it out. That being said, I've just built 3.6p1 packages and put the > key generation stuff from the initscript into the %post section of the > openssh-server package.
Logical move on your part. This does guarantee that it gets run right. The big surprise was that it was possible to run like this. That and the fact that no one in cooker noticed it... self included. Honestly I did think it could be done... guess I was wrong. *grin*. James
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
