Slow connection performance with ssh2

[Robert Dahlem]

Hi,

since I switched from SSH 1 to OpenSSH 2.9p2/2.9.9p2/3.0p1 Snapshot I suffer from 
awfully slow connection performance. Once the connection is established, performance 
is perfectly ok.

   Client                             Server (protocol 2 only)

   # time ssh -p 22222 xx id          # time sshd -d -p 22222
   real    0m13.340s                  real    0m13.900s
   user    0m7.860s                   user    0m7.530s
   sys     0m0.170s                   sys     0m0.240s

Well, this is not the coolest hardware around and the problem is not really existent 
betweeen other machines with 4 SPARC III 64bit at 300 MHz. :-)

The line between the machines operates at 2MBit/s and was nearly idle while testing. 
Its the same when both machines are on 100BaseT, so it seems to have to do with CPU 
consumption while doing the initial key exchange.

I wrote myself a little program sniffing on the debug output and timestamping each 
line with the time difference to the previous line. I attached both and also tried to 
format the output. Here is the outcome:

Client                                 Server
=============================================================================
Connecting to xx [x.x.x.x] port 22222.
Allocated local port 994.                Connection from y.y.y.y port 994
                                         Client protocol version 2.0
********* 4.430 seconds                  Client software version OpenSSH_3.0p1
Remote protocol version 1.99
remote software version OpenSSH_3.0p1
SSH2_MSG_KEXINIT sent                    SSH2_MSG_KEXINIT sent
SSH2_MSG_KEXINIT received                SSH2_MSG_KEXINIT received
SSH2_MSG_KEX_DH_GEX_REQUEST sent         SSH2_MSG_KEX_DH_GEX_REQUEST received
expecting SSH2_MSG_KEX_DH_GEX_GROUP      SSH2_MSG_KEX_DH_GEX_GROUP sent
********* 3.330 seconds                  ********* 3.39 seconds
dh_gen_key: priv key bits set: 134/256   dh_gen_key: priv_key bits set: 126/256
bits set: 1573/3191                      bits_set: 1582/3191
SSH2_MSG_KEX_DH_GEX_INIT sent            expecting SSH2_MSG_KEX_DH_GEX_INIT
expecting SSH2_MSG_KEX_DH_GEX_REPLY      bits set: 1573/3191
                                         ********* 4.260 seconds
********* 4.730 seconds                  SSH2_MSG_KEX_DH_GEX_REPLY sent
check_host_in_hostfile                   kex_derive_keys
Host 'xx' is known and matches RSA key   newkeys: mode 1
bits set: 1582/3191                      SSH2_MSG_NEWKEYS sent
********* 3.910                          waiting for SSH2_MSG_NEWKEYS
ssh_rsa_verify: signature correct
kex_derive_keys
newkeys: mode 1
SSH2_MSG_NEWKEYS sent
waiting for SSH2_MSG_NEWKEYS             ********* 4.110
newkeys: mode 0                          newkeys: mode 0
SSH2_MSG_NEWKEYS received                SSH2_MSG_NEWKEYS received
done: ssh_kex2.                          KEX done

I also tried apptrace: There is a total of 13248 library calls on the client side of 
which are 6641 to libcrypto.so.0.9.6:BN_is_bit_set() and 1905 to libc.so.1:malloc().

I'm pretty sure all this user time spent for generating and checking keys on the 
server and the client add together to the total real time, so client and server are 
nearly always waiting for the other end to finish its calculations.

Is there any way to reduce the CPU cost of key generation and checking in the 
connection phase without sacrificing security?

TIA for any hint (except those attempting to sell me some decent hardware :-).

Regards,
        Robert


-- 
Robert.Dahlem at siemens.com
Siemens Business Services - FS GF KORDOBA-Outsourcing
Tel: +49-69-797-6530  Fax: +49-69-797-6599
----------------------------------------------------------------------
Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email
software; far better than Outlook. Try it sometime.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 12742 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011104/2ea7f35f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 8099 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011104/2ea7f35f/attachment-0001.obj