ssh 连接缓慢解决方法
项目组的服务器，通过SSH服务远程访问Linux服务器，总是等待很久才能登陆。
试过下面的方法，再通过SSH服务远程访问Linux服务器，瞬间登陆。。。甚是开心。。。
vi /etc/ssh/sshd_config
关闭 SSH 的 DNS 反解析,添加下面一行:
UseDNS no
※虽然配置文件中[UseDNS yes]被注释点，
但默认开关就是yes...(SSH服务默认启用了DNS反向解析的功能)
#############################################################
上网查了相关的资料：↓
在目标服务器上有一个文件/etc/nsswitch.conf ，里面有如下一行
hosts： files dns
这行的含义是对于访问的主机进行域名解析的顺序，是先访问file，也就是/etc/hosts文件，如果hosts中没有记录域名，则访问dns，进行域名解析，如果dns也无法访问，就会等待访问超时后返回，因此等待时间比较长。那如果将这一行屏蔽掉是不是也可以达到同样的效果呢？应该是可以的，但是如果本机要通过域名访问其他服务器，则肯定无法访问，因此这行应该需要保留。这个问题也提示我们，dns如果不可用，会带来的一些副作用的。
相信很多朋友在使用Linux系统的时候因为安全性的原因摒弃了telnet rlogin 或者X-window，而把openssh作为自己默认的远程登录方式。然而经常会遇到的一个情况是telnet到server速度很快，但是ssh连接的时候却很慢，大概要等半分钟甚至更久。ping的速度也非常好，让人误以为是ssh连接不上。下面说下如何解决这样的问题，最为常见的原因是因为server的sshd会去DNS查找访问clientIP的hostname，如果DNS不可用或者没有相关记录，就会耗费大量时间。
1, 在server上/etc/hosts文件中把你本机的ip和hostname加入
2, 在server上/etc/ssh/sshd_config文件中修改或加入UseDNS=no(这个方法试过了，好用)
3, 注释掉server上/etc/resolv.conf中所有行（关于这个方法：另一台服务器虽然没有按照方法2修改配置文件sshd_config，但是在这台服务器resolv.conf为空，也就是说这个方法也好用）
4, 修改server上/etc/nsswitch.conf中hosts为hosts: files
5, reboot server使配置生效
解决方法：
1、在ssh服务端上更改/etc/ssh/sshd_config文件中的配置为如下内容：
UseDNS no
# GSSAPI options
GSSAPIAuthentication no
然后，执行/etc/init.d/sshd restart重启sshd进程使上述配置生效，在连接一般就不慢了。
2、如果还慢的话，检查ssh服务端上/etc/hosts文件中，127.0.0.1对应的主机名是否和 uname -n的结果一样，或者把本机ip和hostname(uname -n结果)加入到/etc/hosts里。
[root@C64 ~]# uname -n
C64
[root@C64 ~]# cat /etc/hosts
#modi by oldboy 11:12 2013/9/24
127.0.0.1 C64 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.0.18 C64
################
利用ssh -v的调试功能查找慢的原因
其实可以用下面的命令调试为什么慢的细节（学习这个思路很重要）。
[root@C64 ~]# ssh -v root@10.0.0.19
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.0.0.19 [10.0.0.19] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The 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
=======>老男孩老师评：这里就是提示保存密钥的交互提示。
Warning: Permanently added '10.0.0.19' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@10.0.0.19's 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-8
Last login: Tue Sep 24 10:30:02 2013 from 10.0.0.18
在远程连接时如果慢就可以确定卡在哪了。
[root@C64_A ~]# ssh -v oldboy@10.0.0.17
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.0.0.17 [10.0.0.17] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.0.0.17' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
上述配置没配就发现卡到gssapi这。就大概知道是gssapi的问题。
实际上在linux系统优化部分就应该优化SSH服务的此处。
