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
Hi, On Sun, Nov 04, 2001 at 03:18:00PM +0100, Robert Dahlem wrote:> 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/256I have noticed the same - it hangs at these points for a while: debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. <pause, loooong> debug: bits set: 1008/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. <2nd pause, shorter> debug: Got SSH2_MSG_KEXDH_REPLY. As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running with 95% CPU... - the overall CPU time used by sshd for a successful connect is about 2:50 minutes ssh protocol 1 connects take about 5 seconds or so. Now my question to the experts: is this unavoidable? Or maybe a miscompilation of one of the algorithms used on the Sparc hardware? The openssh version I use is "SSH-1.99-OpenSSH_2.5.1 NetBSD_Secure_Shell-20010614" (which comes with NetBSD 1.5.2). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de
Damien, On Mon, 5 Nov 2001 08:49:45 +1100 (EST), Damien Miller wrote:>You can trade connect speed for security by disabling this - delete >or rename $sysconfdir/{primes,moduli}Could you please give an explanation or a pointer to some reading what this trade means?>Using RSA keys for SSH2 authentication helps too.No big deal here (MIPS R4400/250 MHz). I already had RSA, tried to switch to DSA: not worse compared to RSA (RSA is bad enough :-) . 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.
On Mon, 5 Nov 2001, Robert Dahlem wrote:> Damien, > > On Mon, 5 Nov 2001 08:49:45 +1100 (EST), Damien Miller wrote: > > >You can trade connect speed for security by disabling this - delete > >or rename $sysconfdir/{primes,moduli} > > Could you please give an explanation or a pointer to some reading what > this trade means?The aforementioned draft is probably the best place to start. -d -- | By convention there is color, \\ Damien Miller <djm at mindrot.org> | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE)
Gregory Leblanc <gleblanc at linuxweasel.com> wrote:> > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > > with 95% CPU... - the overall CPU time used by sshd for a successful > > connect is about 2:50 minutes > > Older SPARCs in general are bloody slow at encryption operations. Try > upgrading to 2.9.9p2, and make sure that you're -not- using DSA, as > that's REALLY REALLY slow.It is important to use a matching instruction set. My openssl libcrypto was compiled for sparcv8 (with Sun Workshop 5.0, -xO3). When using ssh (client) on old sun4c (sparcv7) machines like IPX or SS2, ssh login took almost 2 minutes. When a libcrypto was built specially for sparcv7, this was reduced to 17 seconds -- of course, still much too slow. A Sparc LX has about the same speed as an IPX but is sparcv8a (almost v8); but if your libcrypto happens to be compiled for UltraSPARC (v8plus), you may have a similar effect as I had. AFAIK, gcc uses sparcv8 by default.