I executed the following:

%ssh -1 -v dakkon
OpenSSH_2.5.1 NetBSD_Secure_Shell-20010614, SSH protocols 1.5/2.0, OpenSSL 0x0090581f
debug: Reading configuration data /etc/ssh.conf
debug: Rhosts Authentication disabled, originating port will not be trusted.
debug: ssh_connect: getuid 100 geteuid 100 anon 1
debug: Connecting to 10.0.1.32 [10.0.1.32] port 22.
debug: Connection established.
debug: identity file /home/simmons/.ssh/id_dsa type 3
debug: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug: match: OpenSSH_3.4p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug: Local version string SSH-2.0-OpenSSH_2.5.1 NetBSD_Secure_Shell-20010614
debug: send KEXINIT
debug: done
debug: wait KEXINIT
debug: got kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug: got kexinit: ssh-rsa,ssh-dss
debug: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug: got kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug: got kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug: got kexinit: none,zlib
debug: got kexinit: none,zlib
debug: got kexinit: 
debug: got kexinit: 
debug: first kex follow: 0 
debug: reserved: 0 
debug: done
debug: kex: server->client 3des-cbc hmac-sha1 none
debug: kex: client->server 3des-cbc hmac-sha1 none
debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST.
debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP.
debug: Got SSH2_MSG_KEX_DH_GEX_GROUP.

It hangs here for awhile - about 30 seconds

debug: bits set: 2046/4095
debug: Sending SSH2_MSG_KEX_DH_GEX_INIT.
debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY.
debug: Got SSH2_MSG_KEXDH_REPLY.
debug: Host '10.0.1.32' is known and matches the RSA host key.
debug: Found key in /home/simmons/.ssh/known_hosts2:1
debug: bits set: 2053/4095

Then hangs here about the same length of time - about 30 seconds

debug: ssh_rsa_verify: signature correct
debug: Wait SSH2_MSG_NEWKEYS.
debug: GOT SSH2_MSG_NEWKEYS.
debug: send SSH2_MSG_NEWKEYS.
debug: done: send SSH2_MSG_NEWKEYS.
debug: done: KEX2.
debug: send SSH2_MSG_SERVICE_REQUEST
debug: service_accept: ssh-userauth
debug: got SSH2_MSG_SERVICE_ACCEPT
debug: authentications that can continue: publickey,keyboard-interactive
debug: next auth method to try is publickey
debug: try pubkey: /home/simmons/.ssh/id_dsa
debug: read SSH2 private key done: name dsa w/o comment success 1
debug: sig size 20 20
debug: ssh-userauth2 successful: method publickey
debug: fd 5 setting O_NONBLOCK
debug: fd 6 IS O_NONBLOCK
debug: channel 0: new [client-session]
debug: send channel open 0
debug: Entering interactive session.
debug: client_init id 0 arg 0
debug: channel request 0: shell
debug: channel 0: open confirm rwindow 0 rmax 32768
Last login: Thu Mar 13 19:57:46 2003 from dakkon
Welcome to Darwin!
[TiBookDVI:~] simmons% 


I don't see any DNS failures. Will I?

Any Clues?

Gerry Simmons
simmons@darykon.cet.com


On Thu, Mar 13, 2003 Greg Troxel wrote:
> 
> You should use 'slogin -v' and see which step is slow.
> One possible problem is DNS timeouts.
> 
> SSH version 2 does a DH key exchange, and then authenticates the
> exchange/user.  Symmetric encryption is fast, even on really slow
> machines.  I presume login is slow, and then typing/echoing is quick.
> 
> You did not give the hardware on both ends.  From a 933 MHz PIII to a
> 100 MHz Sparcstation 20, with 2048 bit DH keys, it takes about 6
> seconds to do 'ssh -2 -v other.machine.org id'.  The sparc is the slow
> half in this exchange (although I built openssl with -mv8 or some
> such).  Your 233 MHz Pentium should be at least this fast.  Asumming
> it is a P5 and not a P6, I'd expect more like 1-2s with 2048 bit keys.
> 
> See /etc/moduli on both ends.  At least at some point in the past, the
> default was to do a 4096-bit DH exchange.  I don't understand the
> negotiation to determine key size, or how it avoids an attacker
> manipulating it to a low value, but if you remove the > 2048 bit lines
> in /etc/moduli, you will see smaller keys and faster connections.
> 
> Examine the output from -v; the following shows a 2049-bit group:
> 
>   debug1: SSH2_MSG_KEXINIT sent
>   debug1: SSH2_MSG_KEXINIT received
>   debug1: kex: server->client aes128-cbc hmac-md5 none
>   debug1: kex: client->server aes128-cbc hmac-md5 none
>   debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
>   debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
>   debug1: dh_gen_key: priv key bits set: 127/256
>   debug1: bits set: 1050/2049
>   debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>   debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>   debug1: Host 'other.machine.org' is known and matches the DSA host key.
>   debug1: Found key in /home/foo/.ssh/known_hosts:5
>   debug1: bits set: 998/2049
>   debug1: ssh_dss_verify: signature correct
>   debug1: kex_derive_keys
> 
> How much key you need is an interesting question.  It depends on your
> threat model, really.  I would be surprised if using a 2048-bit group
> were the weak link in most systems.
> 
>         Greg Troxel <gdt@ir.bbn.com>
>