> Not to stir up a hornet's nest of debate,
I hope I don't act like a hornet!
> but I've been testing ssh1 and
> ssh2 in both static mode and inetd mode to determine if we want to move to
> static mode as we bring up a new server in the near future. The tests are
> from an old, but reliable Sparc10 (pat, pat, good boy) to a new Enterprise
> 250 running dual UltraSparcII CPUs. What I'm subjectively finding is...
>
> 1. Running sshd1 statically clearly presents a significant reduction of
> wait time over inetd mode. The key bit-size is 768. Static mode wins.
>
> 2. Running sshd2 statically presents *no* reduction of wait time over
> sshd2 in inetd. Key bit-size is 1024. So, it appears superficially that
> sshd2's larger key negates any enhancement created by running sshd2 in
> static mode. As well, I do not see any way of reducing this size in the
> man page for sshd2 (no -b option presented) as is possible with sshd1. Am
> I missing something here? Also, since multiple requests to a static sshd
> daemon result in multiple forked child processes, how is this superior to
> multiple daemon processees spawned by inetd? I'm ready to switch to static
> mode, but I need my curiosity satisfied first.
The multiple sshd1 daemons use the same key-pair (the one that's regenerated
every hour or so). This is safe(ish) because it's the public key that's
sent to the client; the client uses this to encrypt a random session key
to be sent to the server; and different clients will (almost always!)
generate different session keys.
I'm afraid I havn't studied the version 2 protocol enough yet to comment
properly on the reasons sshd2 soesn't seem to get the same advantage from
being run as a static daemon, but my guess would be that it's more likely
that however it's started, it is always generating a key pair for each
connection.
Changing the subject a bit from what's happening to some implications...
I'm currently running sshd1 in static mode. *If* I want my server to accept
both version 1 and version 2 connections from clients I have to run sshd2
and allow it to call sshd1 the same way that inetd would if the incoming
connection turns out to be version 1.
Your results imply it would be better to have sshd1 running in static
mode and for it to call sshd2 the same way it would be called from inetd
if the connection turns out to be version 2. This would, of course,
require patches to sshd1 similar to those included in sshd2, but it might
be worth doing in the light of your results.
--
David Pick
[EMAIL PROTECTED]
