---In message <20020305210706.14fb842d.list@lostgeneration.freeserve.co.uk>
>
>I'm trying to connect to my NetBSD/sparc 1.5.2 machine from a linux box
>running OpenSSH 3.02p1. It will connect but there is a delay of several
>minutes before the password prompt.

I've seen similar delays. They only appear when using v2 of the SSH
protocol. v1 is fast. My initial theory is that the key sizes for v2 are
so large they outstrip the computational abilities of the slower
microSPARC (sun4m) CPUs.  I'd love come to a different conclusion and have
a more workable ssh v2 on my NetBSD machines.

The host info is this:

brahma:	        SPARC-5 (170 MHz) 32 MB RAM, stock NetBSD 1.5.2
		 (OpenSSH_2.5.1 that comes with 1.5.2)

ragno:		Ultra-30 (300 MHz) (Solaris 8, OpenSSH 3.0.2p1)

nanabozho:	Ultra-30 (300 MHz) (Solaris 8, OpenSSH 3.0.2p1)

Results:
-------

ragno	  sshv2 ->  brahma:  0m43.258s until "password:"

nanabozho sshv2 ->  ragno:   0m2.756s until "password:"

brahma	  sshv2 ->  ragno:   4m47.350s until "password:"


ragno	  sshv1 ->  brahma:  0m2.287s until "password:"

nanabozho sshv1 ->  ragno:   0m0.727s until "password:"

brahma	  sshv1 ->  ragno:   0m1.112s until "password:"

During the periods of delay, when i run top on brahma, sshd or ssh is using
all the available CPU.

  When i start sshd like so on brahma :

sshd -d

I get this upon the connect from the other machine :

debug1: Server will not fork when running in debugging mode.
Connection from 64.124.107.148 port 54214
debug1: Client protocol version 2.0; client software version OpenSSH_3.0.2p1
debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_2.5.1 NetBSD_Secure_Shell-20010614
debug1: Rhosts Authentication disabled, originating port not trusted.
debug1: list_hostkey_types: ssh-dss
debug1: send KEXINIT
debug1: done
debug1: wait KEXINIT
debug1: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug1: got kexinit: ssh-rsa,ssh-dss
debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug1: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se
debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug1: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug1: got kexinit: none
debug1: got kexinit: none
debug1: got kexinit: 
debug1: got kexinit: 
debug1: first kex follow: 0 
debug1: reserved: 0 
debug1: done
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: Wait SSH2_MSG_KEX_DH_GEX_REQUEST.
debug1: Sending SSH2_MSG_KEX_DH_GEX_GROUP.

 (This is where the first delay of about 25 seconds hits.)

debug1: bits set: 1026/2049
debug1: Wait SSH2_MSG_KEX_DH_GEX_INIT.
debug1: bits set: 1020/2049

 (Then another delay of 20 seconds here)

 -johan