on Thu, Mar 14, 2002 at 03:49:39AM -0500, Brian A. Seklecki wrote:
> there is one issue of concern that seems to have been neglected.  I know
> this suggestion isn't going to make a lot of users w/ slower hardware
> platforms very happy be cause of the need for increased CPU time for:
> 
> *) Server key regeneration at KeyGenerationInterval

KeyRegenerationInterval is only used with SSH1. So using SSH2 would be a 
decrease in CPU time with this, afaik.

> *) Session key exchange times

openssh3.x seems to improve these times. But it is still slower than
ssh1. ~7 minutes to shell into a sparcstation1 with openssh 2.5.1, as
opposed to ~56 seconds to shell in with openssh 3.0.1 and ~10 seconds
with openssh 3.0.1 ssh1. (This is not a scientifically timed thing,
just a "Oh I haven't upgraded that box yet, let's time it then upgrade
and time again.")

> But is convenience worth sacrificing security integrity?

If users aren't aware that shelling into their Linux 486 is faster than
shelling into the same box running NetBSD is because NetBSD defaults to
SSH2, it's going to lead to "NetBSD is so much slower than Linux, I think
I'll stick with Linux." s/Linux/whateveros/g

As long as a secure default is documented with the fact it does cause
this slow down and you can speed it up, sacrificing security, by using
SSH1, then I think it's a good idea.

> *) Consequently the first run (rc.d/sshd keygen) will run more quickly as
> there will only be 1 key to generate as opposed to 3.

DSA key generation is much slower than RSA. Time for RSA key generation
becomes quite small compared to DSA. I think it's a good idea to keep
all three keys generated, because otherwise if /etc/ssh/sshd.conf
is changed so SSH1 is enabled, there won't be an RSA1 key for it to use.

> *) This is an abrasive move in terms of backward compatibility.  Many
> users with legacy commercial ssh terminals in a production environment may
> be force to upgrade (we all know what it's like to hear DBAs bitch and
> moan).

It just takes the admin either: 1) arguing for migration from SSH1
clients to SSH2 clients, 2) enabling SSH1 in sshd.conf.

> The general consensus among the security community seems to be in favor of
> disabling protocol 1, so I don't see any reason OpenSSH continues to ship
> with it enabled, and more importantly, why we shouldn't take this
> advantage to take a hard-line.

OpenSSH is a secure reimplementation of SSH (the implemenation) not
a secure implementation of SSH (the protocol), imho.