☰

SSH 延迟过长。如何修复 resolve.conf 问题

tag-icon • tag-icon ssh vpn
SSH 延迟过长。如何修复 resolve.conf 问题

我有一台 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 客户端连接到我公司的网络，看起来这些条目是由 VPN 客户端自动添加的。

如何在不中断 VPN 客户端/连接的情况下解决这些长时间延迟问题。我不介意从我的服务器通过 VPN 连接时无法使用我公司的服务器名称/别名，但我想修复连接到服务器时的长时间 SSH 延迟问题。

===========================

  1. 是的，我的意思是 /etc/sshd_conf

  2. 我正在使用 IP 地址直接连接

  3. 我没有使用 VPN 连接到我的服务器（存在延迟）。但是，服务器上正在运行 VPN 客户端以进一步连接到其他网络。使用 VPN 客户端从我的服务器登录速度足够快。

  4. 抱歉，我不明白 AddressFamily、inet 和其他一些评论。

以下是客户端的调试日志（大约有延迟）：

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 秒的暂停

然后它检查指纹等并快速连接。

答案1

sshd_conf

只是为了确定你真的想/etc/ssh/sshd_config，而不是 sshd_conf，对吗？我认为 sshd_conf 或 sshd.conf 不是 Ubuntu 上 OpenSSH 的有效文件，因此编辑它们不会有任何作用。

我从某处读到过，此处的多个名称服务器条目可能会导致问题。

/etc/resolv.conf 中的多个名称服务器不会造成任何问题，但如果列表中的第一个名称服务器速度较慢，则会影响您的系统。事实上，在 /etc/resolv.conf 中列出冗余名称服务器是一种很好的做法，以防一个名称服务器出现故障。

在深入挖掘之前，请尝试确定该问题出在客户端还是服务器端。

在客户端，打开 SSH 详细模式。这将告诉您客户端与服务器的连接进度。如果从客户端到服务器的连接速度很慢，您可能会在出现“debug1：已建立连接。”或“debug1：服务器接受密钥：pkalg ssh-dss blen 435”等行之前看到延迟。

在服务器端，在单独的窗口中跟踪 SSH 日志并查看日志。您可能希望将日志记录增加到“VERBOSE”。

更新：

不要使用 sshd_conf。将以下内容添加到 /etc/ssh/sshd_config ，重新启动 SSH，然后让我们知道发生了什么。

UseDNS no

每次只改变一件事。如果 UseDNS 不起作用，请尝试“GSSAPIAuthentication no”。

答案2

您应该能够在 ~/.ssh/config 中创建自己的用户级配置文件

从这里，您可以将主机映射到数字 IP，这样它应该会完全绕过 DNS 查找。例如，假设您想通过 ssh 连接到“glitch.somewhere.net”，请在您的配置文件中执行以下操作：

Host glitch

  HostName 192.168.0.1
  User JP19

您可以在此处插入大量选项，如 ssh_config 手册页 (man ssh_config) 中所述。这里的关键是“HostName”实际上设置为数字 IP，而不是真正的主机名。本质上，您正在设置多个快捷方式。因此，您可以 ssh 到 glitch1、glitch2、goog……

一个潜在的陷阱是确保权限设置正确，这样 ssh 才不会崩溃。另外，我建议以详细模式 (ssh -vvv) 运行 ssh，以确保它挂在您认为的位置，但我认为您的思路是正确的。

答案3

第一个问题，您是通过 IP 地址还是通过域名连接到服务器？

第二个问题，您可以从外部连接到服务器，还是只能通过 VPN 连接到服务器？

延迟的可能原因是 VPN 和连接速度，不一定是 SSH 连接的结果。

答案4

问题

我在用 Fedora 笔记本电脑登录 CentOS/Fedora 服务器时也遇到了类似的问题。从外部网络连接时，登录过程很快，在密码提示出现之前会有两秒甚至三秒的延迟。但是，从内部网络连接时，需要 10-20 秒才能到达密码提示。

解决方案：

编辑 ~/.ssh/config

Host 192.168.0... (your target ip)
GSSAPIAuthentication no
PasswordAuthentication yes
ChallengeResponseAuthentication no
ForwardX11 yes

确保 ~/.ssh/config 权限对于组/其他人来说是只读的，对于用户来说是只写的。（chmod 为 644）。

相关内容