我有一个Ubuntu 9.04服务器。 在面对服务器进行SSH时，我面临着很长的延迟。 我在sshd_conf中添加了“UseDNS no”，并在ssh_conf中注释掉了“GSSAPIAuthentication yes”，问题依然存在。
看到/etc/resolve.conf ，看起来问题就在那里。
/etc/resolve.conf内容：
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.xx.xx.xx nameserver 10.xx.xxx.xx search xyz.com
我在某处读到多个名称服务器条目可能会导致问题。 我正在使用该服务器上的VPN客户端连接到我公司的networking，看起来这些条目是由vpn客户端自动添加的。
如何解决这些长时间的延迟，而不会打破我的VPN客户端/连接。 我不介意在通过服务器上的VPN连接时无法使用公司服务器名称/别名，但是希望在连接到服务器时修复较长的SSH延迟。
===========================
是的，我的意思是/ etc / sshd_conf
我正在使用IP地址直接连接
我没有使用VPN连接到我的服务器（有延迟）。 但是，服务器上正在运行VPN客户端以进一步连接到其他networking。 从我的服务器使用VPN客户端login是足够快的。
对不起，我不明白AddressFamily，inet和其他一些评论。
这里是客户端的debugging日志（大约延迟）：
OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Connecting to ...... debug1: Connection established. debug1: identity file ..... type -1 debug1: identity file ..... type -1 debug1: identity file ..... type -1 debug1: identity file ..... type -1
现在有4秒暂停
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 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
现在有15-20秒的暂停
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
现在有40-50秒暂停
然后检查指纹等快速连接。
sshd_conf
可以肯定的是，你的意思是/ etc / ssh / sshd_config ，而不是sshd_conf，对不对？ 我不认为sshd_conf或sshd.conf是Ubuntu上的OpenSSH的有效文件，所以编辑它们什么都不做。
我在某处读到多个名称服务器条目可能会导致问题。
/etc/resolv.conf中的多个名称服务器不应该引起任何问题，但如果列表中的第一个名称服务器速度很慢，则会影响您的系统。 实际上，在一个名称服务器出现故障的情况下，在/etc/resolv.conf中列出多余的名称服务器是一个好习惯。
在深入挖掘之前，尝试确定这个问题是在客户端还是服务器端。
在客户端，打开SSH详细模式。 这将告诉你客户端连接到服务器的进度。 如果从客户端到服务器的连接速度很慢，则可能会在“debug1：Connection established”之前看到延迟。 或“debug1：服务器接受密钥：pkalg ssh-dss blen 435”。
在服务器端，将SSH日志放在单独的窗口中并观察日志。 您可能需要将日志logging增加到“VERBOSE”。
更新：
不要使用sshd_conf。 将以下内容添加到/ etc / ssh / sshd_config中，重新启动SSH，然后让我们知道发生了什么。
UseDNS no
一次改变一件事。 如果UseDNS不起作用，则尝试“GSSAPIAuthentication no”。
您应该能够在〜/ .ssh / config中创build您自己的用户级configuration文件
从这里你可以映射主机到数字IP，它应该绕过DNS查找。 例如说你想ssh到“glitch.somewhere.net”，在你的configuration文件中做一些事情：
Host glitch HostName 192.168.0.1 User JP19
您可以在ssh_config手册页（man ssh_config）中描述，在这里插入大量的选项。 这里的关键是“HostName”实际上被设置为一个数字IP而不是一个真正的主机名。 基本上你正在设置多个快捷方式。 所以你可以ssh到glitch1，glitch2，goog，…
一个潜在的问题是要确保权限设置正确，以防ssh不会被吓倒。 另外，我build议在详细模式（ssh -vvv）下运行ssh以确保它挂在你认为的地方，但是我怀疑你是在正确的路上。
第一个问题，你是通过IP地址连接到服务器还是通过域名？
第二个问题，你能够连接到服务器外部或只能通过VPN？
延迟的可能原因是VPN和连接速度，不一定是SSH连接的结果。
你可以试试AddressFamily inet吗？ 它禁用ipv6触发一些旧系统中的错误（它是在openssh常见问题）。
也许有点傻，但你做了更改后重新启动SSH服务器？
问题
我从Fedora笔记本电脑login到CentOS / Fedora服务器也遇到类似的问题。 当从外部networking连接时，这个过程很快，在密码提示出现之前，有两个，也许是三秒的延迟。 但是，从内部networking连接，需要10-20秒才能到达密码提示。
解答 ：
编辑〜/ .ssh / config
Host 192.168.0... (your target ip) GSSAPIAuthentication no PasswordAuthentication yes ChallengeResponseAuthentication no ForwardX11 yes
确保〜/ .ssh / config权限对群组/其他人是只读的，只写给用户。 （chmod到644）。
使用SSH时的日志延迟也可能是被阻塞的进程和/或cron-jobs错误configuration引起的，所以也要检查它们（即crontab -l）