Ubuntu ssh shell 访问在一段时间无人看管后变得无响应

Question

在您的 shell 会话或 SSH 连接完全空闲后，极少数超时可能会终止它。通常您会收到通知。您的 SSH 客户端仅在您尝试执行某项操作后断开连接，这意味着它不知道连接已断开，尝试使用它，然后才认为它已终止。

可能的原因是客户端和服务器之间的某个有状态网络节点“忘记”了连接状态，因为很长时间没有数据包传输。设备认为连接已终止并释放其资源。例如，它可能是您的家用路由器，它实现了NAT。

通常，TCP 连接通过交换和确认 FIN 数据包来终止。这样，任一端都知道连接已终止。此外，监控连接的中间设备（如带有 NAT 的家庭路由器）也知道现在可以忘记它了。

但有时设备（终端设备或中间设备）允许将连接视为已终止，而无需 FIN 数据包。这是因为一端或两端物理断开、强制终止、存在错误等。数据停止流动，您不想永远处理连接，永远希望它有一天继续下去。这种“永恒”连接会积累并耗尽设备的资源。在超时后忘记它们是件好事。

但是，如果您的特定连接完全空闲，则可能会超过超时时间。只有在您稍后尝试发送更多数据后，您才会发现连接已断开。请注意，如果中间设备是罪魁祸首，那么另一端（在您的情况下是服务器）可能仍“认为”连接已建立。

即使您可以重新配置中间设备并增加其超时时间，这也不是一个解决方案。需要一定的超时时间。如果超时时间非常短（我不认为是短），这可能是解决方案的一部分。

真正的解决方案是时不时地交换一些数据包，这样连接就不会完全空闲。如果在相关超时到期之前发送数据包，则应该重置超时。

尽管你的 shell 会话处于空闲状态，但有几种方法可以让连接看起来繁忙：

TCP 保持连接。请参阅我的这个答案，第一部分服务器端的故事部分。附加说明以更好地解决您的案例：
- TCPKeepAlive属于客户端和服务器端的配置。这意味着您可以ssh在客户端或/和服务器端拥有。sshdTCPKeepAlive yesssh_configsshd_config
- 如果您的连接已使用TCPKeepAlive yes，并且我对中间设备的假设是正确的，那么该参数tcp_keepalive_time可能太高，无法防止设备超时。您可以考虑降低该参数。
- 请注意， /TCPKeepAlive配置启用了 SSH 连接的功能，但其他设置（如）是系统范围的。sshsshdtcp_keepalive_time
此机制的主要目的是让操作系统判断看似空闲的连接是否真的空闲。更新中间设备的超时是副作用。我认为中间设备（如实现 NAT 的路由器）可能会生成 TCP keepalive 消息（模拟连接的真实参与者）以检查它是否可以“忘记”连接而不会产生任何后果。在您的情况下，如果此类设备是罪魁祸首，它显然不会这样做。
SSH 特定的ClientAliveInterval和ServerAliveInterval。前者属于sshd_config（在服务器上），后者属于ssh_config（在客户端上）。有关详细信息，请参阅man 5 sshd_config和。请注意，您还可以通过在命令行中将它们传递给来man 5 ssh_config指定（属于的）选项。例如此命令：ssh_configssh
```
ssh -o ServerAliveInterval=300 user@server
```
将在 5 分钟不活动后让ssh请求得到服务器的响应。

此机制的主要目的是允许sshd/ssh判断看似空闲的连接是否真的空闲（调查ClientAliveCountMax和ServerAliveCountMax）。同样，更新中间设备的超时是一个副作用。
确保控制台中有任何可见的活动。每隔几分钟打印一些内容的后台脚本很麻烦且不雅观，但它仍然可以工作。你绝对应该更喜欢ServerAliveInterval。我提到这一点是因为
- 从技术上来说这是一个解决方案；
- 如果您选择在服务器上使用tmux，那么它将每分钟更新您的控制台（因为其默认状态行中的时钟），这足以保持建立的连接。

最后说明：

请注意 (1) 和 (2) 的主要目的。如果您仅在一端使用其中任何一种，并且连接由于某种原因中断，另一端可能不会注意到。当连接尚未中断时，任何一端的修复都足以更新中间设备上的超时。
一般来说，任何连接都可能中断，因此最好做好准备；因此tmux无论如何都要在服务器上考虑。

Answer 1