远程linux主机显示终端提示符大约15秒延迟的可能原因是什么

远程linux主机显示终端提示符大约15秒延迟的可能原因是什么

当我尝试ssh登录 Linux 主机时,在本地计算机上输入 ssh 命令后,大约 15 秒后会显示终端提示符。随后的连接需要 2-3 秒。然而,等待一段时间后,与远程主机断开连接并重新连接后ssh,所需时间与第一次相同。

  • 操作系统是 Amazon Linux 2。
  • CPU和网络图显示前后没有异常。
  • UseDNS中被注释掉了/etc/ssh/sshd_config

我应该看看哪些可能的地方。

答案1

既然你说“Amazon Linux 2”,那么这是云主机吗?

如果是这样,可能只是需要花费大量时间来确定您的主机当前在云中的确切位置,并创建适当的 NAT 映射来将您的 SSH 连接路由到那里。但是,如果已经存在现有连接,则映射已经生效,并且您的第二个和后续连接将建立得更快。

如果您的云主机中没有任何特定的运行,云提供商甚至可能在检测到主机完全空闲且没有网络连接时自动挂起主机,以节省电量。或者,他们可能会将虚拟主机迁移到数据中心的不同硬件单元以优化其负载,而第一个传入的 SSH 连接只会触发 CPU 资源与网络连接方面的重新优化,可能会导致您的虚拟机迁移到不同的硬件单元。

基本上,这是您应该询问托管提供商的问题。

答案2

从您的描述中不清楚延迟发生在哪里。考虑在命令行上按“回车”后所涉及的步骤。

  1. 您的计算机解析其 ssh 配置。既然你问这个问题,这不太可能是一个很大的开销,但即使是非常复杂的配置通常也可以快速处理

  2. 您的计算机向(第一个)ssh 端点发出 DNS 请求,并且需要等待回复。如果没有回复,将会超时大约 30 秒。请注意,可能存在多个跃点,具体取决于访问的配置方式。

  3. 您的计算机开始与端点进行 TCP 握手。正如 telcoM 所说,如果有一些巧妙的路由和/或防火墙发生,这可能需要一些时间。通过限制连接来缓解 DOS 的情况并不罕见。

  4. 服务器提供其公钥,然后由您的计算机进行验证。

  5. 服务器开始执行 shell,运行所有启动文件。这意味着准备好很多不一定在缓存中的文件。这可能包括显示横幅消息、配置路径和提示。

  6. (可选)如果这是跳转主机,则服务器成为下一跳的客户端,并执行步骤2-5

  7. 您收到来自远程系统的提示

ssh 将多路复用连接,因此当您建立第二个连接时,您将从步骤 5 开始。

使用ssh -v(或更好ssh -vvv)可以让您深入了解这些步骤所需的时间。

答案3

潜在原因太多,没人能一一列举全部,尝试随机出现的想法可能会花费很长时间。

(我见过由于调用配置错误的 LDAP 而导致响应缓慢、缺乏适当的索引而导致速度变慢。我见过由于非常繁忙的 VM 主机上的内核中的性能错误而导致速度变慢。这可能非常棘手追踪此类问题。)

相反,我建议您尝试找出登录时花费在哪里。

我会从这样的事情开始:

script -fc 'ssh -v server' -t /dev/null

这将导致ssh记录其许多步骤,并将script(在 stderr 上)发出行之间运行的时间。

看一个更简单的例子:

script -fc 'echo a; sleep 1; echo b; sleep 1; echo c' -t /dev/null 
Script started, output log file is '/dev/null', timing file is '/dev/stderr'.
a
0.000733 3
          b
1.000921 3
          c
1.001222 3
          Script done.

在这里我们可以看到“a”和“b”行之间花费了大约 1 秒,“b”和“c”之间又花费了大约 1 秒(script发出计时信息线)。

ssh -v可能非常冗长,以至于您可能希望script在脚本会话中运行该命令本身。 :)

这可能会为您提供一些线索,以确定速度下降是否发生在客户端和服务器之间,或者主要发生在服务器上。

您还可以尝试从服务器本身进行连接,从而消除客户端和服务器之间的延迟。

如果速度下降主要发生在服务器上,您需要查看 ssh 服务器和 PAM 的日志(例如 `journalctl -u ssh -ef),并在连接时密切关注顶部。

相关内容