I have observed the extra overhead of dh-group-exchange to cause people to switch from using SSH-2 back to SSH-1, in several contexts. This is unfortunate, as SSH-2 with the default group is still presumably several miles more secure than SSH-1. The OpenSSH client and server should both allow dh-group-exchange to be turned off (and in general, allow configuration of kex method preferences). Supporting data: On slow machines (e.g., 486-class, old SPARCs), dh-gex takes an unreasonably long time (e.g., 14 seconds for gex followed by kex on a SS20 server). Disabling gex (at the client end - there's a config option in PuTTY) gives a much more sensible delay (2 seconds). Also, from draft-ietf-secsh-architecture-15.txt: The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation: [...] o Public key algorithms and key exchange method to be used for host authentication. (No patch though, sorry. Also, apologies if this has been addressed recently; I was going off the man pages on openssh.com.)
what group size does the client ask for? i don't think it's the additional message in gex, but the group size matters.
Erm, I hadn't taken into account what PuTTY asks for. It appears to use old-style GEX (no min/max) and, I believe, asks for up to a 2048-bit group (don't know offhand what it used in this instance). Even with an OpenSSH_3.4p1 client it's still rather slow, though. I get a 7-10sec delay to the same host (from a reasonably fast client), which I think is enough to cause people to avoid SSH-2. e.g. debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 133/256 debug1: bits set: 1616/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY [delay 8.8sec here] debug1: Host 'foon.spork.example.org' is known and matches the RSA host key.
Created attachment 506 [details] duplicate
Created attachment 507 [details] patch for ssh client. what about this?
Sorry, I haven't had a chance to try this out yet. Is it a harmless performance improvement? (I'm clueless.) Do I take it that you believe the issue of people not using SSH-2 can/should be addressed by performance improvements, rather than by adding performance- related configuration options?
Also, the supplied moduli file has moduli one bit smaller than what sshd is looking for, so it ends up using the next size up resulting in a speed penalty. The combination of Markus' patch (now in -current) and a replacement moduli file (eg http://www.zip.com.au/~dtucker/openssh/moduli) results in a significant improvement. The server is a 170MHz SPARC: $ time ssh -2 myserver true # 3.7.1p2 real 0m2.750s $ time ssh -2 myserver true # new moduli real 0m1.167s $ time ssh -2 myserver true # new moduli+patch real 0m1.130s BTW compiling (openssh+openssl) on SPARCs with v8 instructions (eg "gcc -mv8") enables the use of the hardware multiply which is significantly quicker.
The new moduli file has now been added to OpenSSH (+OpenBSD) too, so snapshots and the next release will have it. Note that if you're upgrading, in most cases moduli will not be replaced by an upgrade, so you'll have to do it yourself.
Still haven't had a chance to try this patch, sorry... While the speedups are welcome, and do a lot to address my original beef - thanks for them - no-one has yet discussed the issue as raised ("dh-group- exchange should be configurable off in client and server" as recommended by the IETF documents). What I'm really after is some sort of statement on the configurability issue - is OpenSSH actively against it (why?), or do you consider it a low-priority wishlist feature, or what? I can change the title of this bug to cover just the performance improvements, and move this discussion to a new bug, if you want.
[..] > What I'm really after is some sort of statement on the > configurability issue - is OpenSSH actively against it (why?), > or do you consider it a low-priority wishlist feature, or what? I'm actively against it. The more options you give a user the more of a chance they will decide to use or not use it based on lack of, or bad, information. Honestly, if you know a machine is underpowered and can't handle this this then it is not hard to mv /etc/moduli /etc/moduli.dead, and be done with it. If it is going to be an issue for the sshd server running on the old machine it will be an issue for the ssh client running on the same machine. - Ben
Created attachment 538 [details] Patch to /etc/moduli description in sshd(8) Added one sentence to make it clearer that removing /etc/moduli will disable DH group exchange.
Ben, thanks for replying. I can see that view. I suggest a one-line change to the sshd(8) man page (attached) which would have made it more obvious to me how to disable this feature. (I still think this is worth doing, as it allows a clueful admin to engineer a better situation on an underpowered server than would arise if users switch back to SSH-1.)
Mass change of RESOLVED bugs to CLOSED