The main reason for the slow connection is that DNS resolution causes

Workaround:

1. Change the configuration in the/etc/ssh/sshd_config file on the SSH server to the following:

Usedns no# GSSAPI optionsgssapiauthentication No

Then, perform/etc/init.d/sshd restart restart the sshd process so that the above configuration takes effect, the connection is generally not slow.

2, if it is still slow, check the SSH server/etc/hosts file, 127.0.0.1 the corresponding hostname and uname-n results, or the native IP and hostname (uname-n result) into the/etc/hosts.

[[email protected] ~]# uname-nc64[[email protected] ~]# Cat/etc/hosts#modi by Oldboy 11:12 2013/9/24127.0.0.1 C64 loca Lhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 Local host6.localdomain610.0.0.18 c64################

Use the Debug function of Ssh-v to find the cause of slowness

In fact, you can use the following command to debug why the slow details (learning this idea is very important).

[[email protected] ~]# ssh -v [email protected]openssh_5.3p1, openssl  1.0.0-fips 29 mar 2010debug1: reading configuration data /etc/ssh/ssh_ configdebug1: applying options for *debug1: connecting to 10.0.0.19 [ 10.0.0.19] port 22.debug1: connection established.debug1: permanently_set_uid: 0 /0debug1: identity file /root/.ssh/identity type -1debug1: identity file  /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_dsa type  -1debug1: Remote protocol version 2.0, remote software version  openssh_4.3debug1: match: openssh_4.3 pat openssh_4*debug1: enabling  compatibility mode for protocol 2.0debug1: local version string  Ssh-2.0-openssh_5.3debug1: ssh2_msg_kexinit sentdebug1: ssh2_msg_kexinit receiveddebug1: kex: server->client  aes128-ctr hmac-md5 nonedebug1: kex: client->server aes128-ctr hmac-md5  Nonedebug1: ssh2_msg_kex_dh_gex_request (1024<1024<8192)  sentdebug1: expecting ssh2_ Msg_kex_dh_gex_groupdebug1: ssh2_msg_kex_dh_gex_init sentdebug1: expecting ssh2_msg_kex_dh _gex_replythe authenticity of host  ' 10.0.0.19  (10.0.0.19) '  can ' t be  Established. Rsa key fingerprint is ca:18:42:76:0e:5a:1c:7d:ef:fc:24:75:80:11:ad:f9. are you sure you want to continue connecting  (yes/no)?  yes======= > Old boy Teacher Comments: Here is the prompt to save the key interactive hints. warning: permanently added  ' 10.0.0.19 '   (RSA)  to the list of known  hosts.debug1: ssh_rsa_verify: signature correctdebug1: ssh2_msg_newkeys sentdEbug1: expecting ssh2_msg_newkeysdebug1: ssh2_msg_newkeys receiveddebug1: ssh2_msg_ service_request sentdebug1: ssh2_msg_service_accept receiveddebug1: authentications  that can continue: publickey,passworddebug1: next authentication method:  Publickeydebug1: trying private key: /root/.ssh/identitydebug1: trying private &NBSP;KEY:&NBSP;/ROOT/.SSH/ID_RSADEBUG1:&NBSP;TRYING&NBSP;PRIVATE&NBSP;KEY:&NBSP;/ROOT/.SSH/ID_DSADEBUG1:  next authentication method: password[email protected] ' s password:=======> Here is an interactive hint that prompts for a password. debug1: authentication succeeded  (password). debug1: channel 0: new [ client-session]debug1: entering interactive session.debug1: sending  Environment.debug1: sending env lang = en_us. Utf-8last login: tue sep 24 10:30:02 2013 from 10.0.0.18 

If you are slow on a remote connection, you can determine where the card is.

[[Email protected]_a ~]# ssh -v [email protected]openssh_5.3p1, openssl  1.0.0-fips 29 mar 2010debug1: reading configuration data /etc/ssh/ssh _configdebug1: applying options for *debug1: connecting to 10.0.0.17 [ 10.0.0.17] port 22.debug1: connection established.debug1: permanently_set_uid: 0 /0debug1: identity file /root/.ssh/identity type -1debug1: identity file  /root/.ssh/id_rsa type -1debug1: identity file /root/.ssh/id_dsa type  2debug1: Remote protocol version 2.0, remote software version  Openssh_5.3debug1: match: openssh_5.3 pat openssh*debug1: enabling compatibility  mode for protocol 2.0debug1: local version string ssh-2.0-openssh_ 5.3debug1: ssh2_msg_kexinit sentdebug1: ssh2_msg_kexinit receiveddebug1: kex: server->client  aes128-ctr hmac-md5 nonedebug1: kex: client->server aes128-ctr hmac-md5  Nonedebug1: ssh2_msg_kex_dh_gex_request (1024<1024<8192)  sentdebug1: expecting ssh2_ Msg_kex_dh_gex_groupdebug1: ssh2_msg_kex_dh_gex_init sentdebug1: expecting ssh2_msg_kex_dh _gex_replydebug1: host  ' 10.0.0.17 '  is known and matches the RSA  Host key.debug1: found key in /root/.ssh/known_hosts:2debug1: ssh_rsa_verify:  signature correctdebug1: ssh2_msg_newkeys sentdebug1: expecting ssh2_msg_ newkeysdebug1: ssh2_msg_newkeys receiveddebug1: ssh2_msg_service_request sentdebug1:  ssh2_msg_service_accept receiveddebug1: authentications that can continue:  Publickey,gssapi-keyex,gssapi-wiTh-mic,passworddebug1: next authentication method: gssapi-keyexdebug1: no valid  key exchange contextdebug1: next authentication method: gssapi-with-mic

The above configuration does not match the discovery card to gssapi this. You probably know it's a gssapi problem.

In fact, the Linux System Optimization section should optimize the SSH service here.

The main reason for the slow connection is that DNS resolution causes