Hi. On Mon 2003-03-31 at 21:18:10 -0700, [EMAIL PROTECTED] wrote: > On Sun Mar 30, 2003 at 09:35:58AM -0800, James Sparenberg wrote: [...] > > -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.
Yes, it is. It's just that the sshd naming is a bit overloaded. What
you are talking about is the "host key". The "server key" is more like
a temporary key ("session key" has it's own meaning, that's why I am
not using it in this context), which is generated once an hour by
default.
Btw, I only know all that, because I understood that the man page
talked about the temporary key and thought "server key" was just a
typo. Then I learned The Truth. ;)
Now, when running from inetd, the server key is generated each time,
which is slow.
> 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.
Correct.
> 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.
I just learned that the server key is only generated for protocol
version 1. Protocol version 2 seems to do without. So if you disabled
Protocol 2, there would be no penatly for generating the server key.
(I do not imply whether running by inetd is a good thing or not. I
just noticed that the key generation issue isn't one anymore).
> As soon as I found out why he did it, I plan to take it out... no one should
> run sshd from xinetd.
Regardless of the current issue, I would really like that "design
decisions" like that would be better documented generally. I am doing
a lot of programming and am used to expect a explainging comment when
a formerly working design is changed. The rpm changelogs are really
short on that. :-/
The thing I find most sad about this is that really capable people are
making these changes and reading those comments could be like being
beaten with a cluestick. :-)
HAND,
Benjamin.
pgp00000.pgp
Description: PGP signature
