解决SSH连接缓慢

[chenjun]

正常通信的情况下，在ssh远程连接OB服务器时会出现这样一种情况，出现login as:非常快，当输入用户名密码后，password要等待半分钟以上才能出现，这种情况主要是服务器所设置的DNS访问缓慢造成的，因为sshd服务会对本地ip地址进行反向解析，向DNS服务器发送PTR查询。解决此问题的办法是在/etc/ssh/sshd_config中禁用DNS功能，修改如下：

代码: 全选

#UseDNS yes
UseDNS no

然后重启sshd服务

代码: 全选

kill -HUP $(cat /var/run/sshd.pid)

[leo]

这也是原因之一，有时候好像只禁止服务器端也未必能解决问题，原因很多，有时候还需要判断，这在官方网站上也没有统一的说法。
http://www.openssh.org/faq.html#3.3

3.3 - ssh(1) takes a long time to connect or log in
Large delays (more than 10 seconds) are typically caused by a problem with name resolution:

• Some versions of glibc (notably glibc 2.1 shipped with Red Hat 6.1) can take a long time to resolve "IPv6 or IPv4" addresses from domain names. This can be worked around with by specifying AddressFamily inet option in ssh_config.
• There may be a DNS lookup problem, either at the client or server. You can use the nslookup command to check this on both client and server by looking up the other end's name and IP address. In addition, on the server look up the name returned by the client's IP-name lookup. You can disable most of the server-side lookups by setting UseDNS no in sshd_config.

Delays less than 10 seconds can have other causes.

• OpenSSH releases prior to 3.8 had an moduli file with moduli that were just smaller than what sshd would look for, and as a result, sshd would end up using moduli significantly larger than requested, which resulted in a speed penalty. Replacing the moduli file will resolve this (note that in most cases this file will not be replaced during an upgrade and must be replaced manually).
• OpenSSH releases prior to 3.8 had a flaw in ssh that would cause it to request moduli larger than intended (which when combined with the above resulted in significant slowdowns). Upgrading the client to 3.8 or higher will resolve this issue.
• If either the client or server lack a kernel-based random number device (eg Solaris < 9, AIX < 5.2, HP-UX < 11.11) and no substitute is available (eg prngd) it's possible that one of the programs called by ssh-rand-helper to generate entropy is hanging. This can be investigated by running it in debug mode:
  [INDENT]/usr/local/libexec/ssh-rand-helper -vvv
  [/INDENT]Any significant delays should be investigated and rectified, or the corresponding commands should be removed from ssh_prng_cmds.

How slow is "slow"?

Under normal conditions, the speed of SSH logins is dependant on CPU speed of client and server. For comparison the following are typical connect times for time ssh localhost true with a 1024-bit RSA key on otherwise unloaded hosts. OpenSSH and OpenSSL were compiled with gcc 3.3.x.
CPUTime (SSHv1)[1]Time (SSHv2)170MHz SPARC/sun4m0.74 sec1.25 sec236MHz HPPA/8200[2]0.44 sec0.79 sec375MHz PowerPC/604e0.38 sec0.51 sec933MHz VIA Ezra0.34 sec0.44 sec2.1GHz Athlon XP 2600+0.14 sec0.22 sec
[1] The SSHv1 protocol is faster but is cryptographically weaker than SSHv2.
[2] At the time of writing, gcc generates relatively slow code on HPPA for RSA and Diffie-Hellman operations (see gcc bug #7625 and discussion on openssh-unix-dev).

[crzyfish]

哦～ 学习了，经常ssh到自己的虚拟机也要等蛮久的～