SSH taking long time

[Nagu SR]

Hi,

I have reinstalled my machine with RedHat Linux AS3 (The server had disk errors; and after replacing the disk we have installed with same OS which was there earlier)

Now whenever I do ssh, it takes long time..Can any one help me please?



abc123:/ # ssh -vv host123
OpenSSH_4.3p2, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): 0509-022 Cannot load module /usr/krb5/lib/libkrb5.a(libkrb5.a.so).
0509-026 System error: A file or directory in the path name does not exist.

debug1: Error loading Kerberos, disabling Kerberos auth.
debug2: ssh_connect: needpriv 0
debug1: Connecting to host123 [10.110.128.10] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /.ssh/id_rsa type 1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug2: key_type_from_name: unknown key type 'from="abc123,abc123.dns.com"'
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 516/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host123' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1922
debug2: bits set: 529/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /.ssh/identity (0)
debug2: key: /.ssh/id_rsa (20052918)
debug2: key: /.ssh/id_dsa (0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/identity
debug1: Offering public key: /.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Sat Oct 9 10:50:14 2010 from abc123.dns.com
*******************************************************************************
* *
* host123 is an Linux RHAS3.0 system protected by eTrust Access Control *
*
* *
*******************************************************************************
[root@host123 root]#

[Steven Schweda]

> [...] whenever I do ssh, it takes long time.

Can you tell what it's doing when the "takes
long time" part happens?

A common cause of apparently slow network
connections is a DNS problem. Many server
programs (like, say, sshd) try to do a
(reverse) address-to-name look-up on the
client's IP address. If that fails (slowly),
then the connection appears to be slow. To
test this, on the server system ("host123"?),
do:
nslookup
and see if that's slow.

[Nagu SR]

Hi Steve,

Its not a problem with Network. ssh was functioning normally before server was reinstalled.

ssh slows down at this below stage..(debuggung messages output -vv)

debug1: Offering public key: /.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug2: channel 0: request shell confirm 0
debug2: fd 4 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072



I suspect, it could be problem with some authentication but I dont know how to fix it.

I may be wrong though

[Steven Schweda]

> It[']s not a problem with Network. [...]

Which means what, exactly? Your opinion is
interesting, but, as usual, showing actual
commands with their actual output (that is,
actual evidence) can be more helpful than
vague descriptions or interpretations, or
opinions.

> [...] on the server system ("host123"?),
> do:
> nslookup
> and see if that's slow.

Did you try that? What happened?

> ssh slows down at this below stage..

Where in that sequence? Beginning? Middle?
End?

Is SSH the only slow thing? Try Telnet?
All users or only this user ("root")?
Anything weird in the shell start-up file(s)?

> I suspect, it could be problem with some
> authentication [...]

When you see "debug1: Authentication
succeeded (publickey).", then I think that
authentication is pretty well complete.

Also, something which I forgot to ask:

> I have reinstalled my machine [...]

Is "my machine" the SSH client here, or the
server? Is this the only machine which has
this problem?

[Viktor Balogh]

Hi,

If an SSH connection seems slow to establish, usually it boils down to name resolution. Check with the dig/host command if the name service responds in time. I suspect this is either a name resolution problem or a routing problem. Either way, it must be on the newly installed server and not on the other parts (network interfaces, remote side), if they weren't changed.

Regards,
Viktor

[Nagu SR]

I have regenerated ssh keys and copied.

Now its all fine.

Thanks