Re: Question performnace of SSH v1 vs SSH v2
Key exchange can be painfully slow, and key generation even more so. If
using the strongest possible algorithm isn't that important to you, then
look into using RC4 (arcfour). On the other end of high speed, SSH2
doesn't scale windows properly and large TCP windows don't affect the
internal SSH window thus cutting performance on high BDP links. SSH1
doesn't have windows so this isn't a problem there.
On Fri, 25 Feb 2005, Darren Tucker wrote:
> Amba Giri wrote:[color=green]
>> I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a
>> report from the field that v2 is perceived to be significantly slower
>> than v1. Is this a known issue? Are there any configuration parameters
>> that can be modified to make v2 faster?[/color]
> In general, SSHv2 is slower because it's stronger.
> That said, there are some things that can be done to speed it up.
> If you haven't already, fiddle with your compiler flags for both OpenSSL and
> OpenSSH. In particular, enabling hardware multiply instructions (eg -mv8 on
> SPARCs) makes a noticable difference to the Diffie-Hellman exchange.
> If you upgraded sshd, make sure you use the moduli file from a recent
> distribution. Older ones had 2kbit moduli that were actually 2k-1
> bits, so sshd would end up using larger ones than requested.
> Older OpenSSH clients would ask for larger moduli than intended too, so newer
> clients ought to be faster too.
> You can also fiddle with the moduli file itself: keep only the lines with a
> generator of 2 (exponentiating 2 may be faster than 5 on some architectures).
> (Most of this only applies if your clients are using DH Group Exchange.)
> There's some more information here:
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> openssh-unix-dev mailing list
openssh-unix-dev mailing list