☰

当反向 ssh 隧道突然/不干净地断开连接时，如何释放 SSH 服务器上的端口？

tag-icon • tag-icon linux networking ssh tunnel
当反向 ssh 隧道突然/不干净地断开连接时，如何释放 SSH 服务器上的端口？

我们在客户处安装了一些硬件，这些硬件连接到我们的 ssh 服务器并建立反向 ssh 隧道，以便我们可以访问多个客户端系统以进行监控。

一切工作正常，直到 SSH 会话意外断开。

当发生这种情况时，在我们的 SSH 服务器上，反向隧道使用的端口将停留在侦听模式，并且当我们的远程硬件最终尝试自动重新连接并重新建立其隧道时，它会失败并显示错误

警告：监听端口 XXXX 的远程端口转发失败

我通过尝试完全断开连接并释放端口来测试我们的 SSH 服务器或客户端是否存在问题。当我模拟连接故障（例如断开客户端硬件的以太网端口）时，我们遇到了上述相同的问题。

处理这种情况的正确方法是什么？请记住，这些是反向隧道，因此无论发生什么，都需要在 SSH 服务器上完成。理想情况下，我需要 ssh 服务器立即意识到托管隧道的 SSH 会话已关闭并释放它正在使用的端口。我猜解决方案可能涉及终止相关的 SSH 进程，但我需要小心处理，因为我们有多个客户端连接到同一个 ssh 服务器，我不想将它们踢出离线。

由于非常成熟，我确信 SSHD 具有某种内置功能来处理这个问题，但我就是无法弄清楚。

请提供建议，这样我就不必再回去管理 Windows 机器了……

仅供参考：我在基于 Debian 的发行版上运行它。

答案1

您必须ClientAliveInterval在您的中使用sshd_config。

ClientAliveInterval 15

参考：sshd_config 命令

ClientAliveCountMax
         Sets the number of client alive messages (see below) which may be
         sent without sshd(8) receiving any messages back from the client.
         If this threshold is reached while client alive messages are
         being sent, sshd will disconnect the client, terminating the
         session.  It is important to note that the use of client alive
         messages is very different from TCPKeepAlive (below).  The client
         alive messages are sent through the encrypted channel and
         therefore will not be spoofable.  The TCP keepalive option
         enabled by TCPKeepAlive is spoofable.  The client alive mechanism
         is valuable when the client or server depend on knowing when a
         connection has become inactive.

         The default value is 3.  If ClientAliveInterval (see below) is
         set to 15, and ClientAliveCountMax is left at the default,
         unresponsive SSH clients will be disconnected after approximately
         45 seconds.  This option applies to protocol version 2 only.

 ClientAliveInterval
         Sets a timeout interval in seconds after which if no data has
         been received from the client, sshd(8) will send a message
         through the encrypted channel to request a response from the
         client.  The default is 0, indicating that these messages will
         not be sent to the client.  This option applies to protocol
         version 2 only.

相关内容