Jim Crumley wrote: > My first suggestion would be to try running ssh -v when you log > into one of the boxes to see if you can find out where it is > spending so much time. Thanks for the idea. Here's the result...I put in a marker where the pause occurs. __________________________________ user at host:~$ ssh -v user2 at host2 OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to host2 [host2] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 debug1: match: OpenSSH_3.4p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 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: 121/256 debug1: bits set: 1559/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'host2' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:2 debug1: bits set: 1576/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT >>>>PAUSE debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try privkey: /home/user/.ssh/identity debug1: try privkey: /home/user/.ssh/id_rsa debug1: try privkey: /home/user/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is password user2 at host2's password: __________________________________ Also, you could try running sshd -d on the > server. You might find some simple misconfiguration is causing > ssh to run through a bunch of steps that it shouldn't be > bothering with. I'll give that a try. Thanks! -Erik _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list