公众号旧文
为什么修改 Linux 服务器时，建议同时建立两条 SSH 连接？
平时管理 Linux 服务器，我们通常只需要打开一个终端，通过 SSH 登录服务器，就可以执行命令、修改配置、查看日志。
但如果你仔细观察一些 AI 编程工具，比如 Codex，在执行服务器配置修改时，有时会发现它同时建立了两条 SSH 连接。
为什么要这样做？一条 SSH 连接不够吗？
其实，同时建立两条 SSH 连接，主要是为了降低远程操作过程中失去服务器控制权的风险。
一、一条 SSH 连接有什么风险？
SSH 是远程管理 Linux 服务器最常用的方式。
正常情况下，我们通过 SSH 登录服务器：
ssh root@192.168.1.100连接成功后，就可以执行各种操作。
如果只是查看 CPU、内存、磁盘使用情况，或者修改普通应用程序的配置，一条 SSH 连接通常足够。
但如果修改的是网络配置，情况就不一样了。
例如：
- 修改 IPv4、IPv6 地址
- 修改默认网关和路由表
- 调整 iptables、nftables 防火墙规则
- 修改 SSH 服务配置
- 调整 Tailscale、WireGuard 等虚拟网络
- 重启网络服务
这些操作有一个共同特点：可能影响 SSH 自身依赖的网络连接。
假设你通过 SSH 修改服务器的默认路由，却不小心将网关地址填写错误。
执行配置后，服务器可能立即失去网络连接，当前 SSH 会话随之中断。
此时，即使你已经知道问题出在哪里，也无法通过 SSH 登录服务器进行修复。
如果服务商没有提供 VNC、Web Console 等带外管理方式，恢复服务器就会非常麻烦。
二、为什么要建立两条 SSH 连接？
双 SSH 连接的思路并不复杂：
一个连接负责操作，另一个连接负责保护和验证。
例如，同时打开两个终端窗口。
第一个窗口：
ssh root@192.168.1.100用于执行配置修改、重启服务等操作。
第二个窗口：
ssh -o ControlMaster=no \
-o ControlPath=none \
root@192.168.1.100用于观察服务器状态，必要时执行恢复命令。
这里额外指定 SSH 参数，是为了避免第二个窗口复用已有的 SSH 主连接，让两次登录尽可能保持独立的客户端连接。
这样做至少有两个好处。
第一，降低单个会话异常带来的影响。
如果操作窗口因为终端关闭、会话异常等原因中断，而服务器网络仍然正常，第二条 SSH 连接可能继续保持可用。
第二，方便验证修改后的连接状态。
例如修改 SSH 服务配置后，原来的连接可能仍然保持正常，但新的 SSH 连接已经无法建立。
通过备用窗口重新发起 SSH 登录，就可以及时发现问题。
需要注意的是，两条 SSH 连接并不意味着服务器拥有两条独立的网络线路。
如果默认路由、防火墙或网络接口出现严重故障，两条 SSH 连接仍然可能同时失效。
因此，双 SSH 只能降低部分风险，不能代替自动回滚机制。
三、哪些场景建议使用双 SSH？
并不是所有服务器操作都需要建立两条连接。
可以根据风险等级进行判断。
| 操作场景 | 是否建议双 SSH |
|---|---|
| 查看系统日志、CPU、内存 | 不需要 |
| 查看磁盘空间、进程状态 | 不需要 |
| 安装普通软件 | 通常不需要 |
| 修改 Nginx 等应用配置 | 通常不需要 |
| 修改 SSH 服务配置 | 强烈建议 |
| 修改防火墙规则 | 强烈建议 |
| 修改 IPv4、IPv6 地址 | 强烈建议 |
| 修改默认网关、路由表 | 强烈建议 |
| 修改 Tailscale、WireGuard 网络 | 强烈建议 |
| 重启整台服务器 | 双 SSH 帮助有限 |
其中，最需要小心的是网络和防火墙相关操作。
例如执行以下命令：
ip route replace default via 192.168.1.1如果新的默认网关不正确，可能导致服务器无法正常访问外部网络，甚至影响当前 SSH 会话。
又比如修改防火墙规则时，不小心阻止了 TCP 22 端口的新连接。
原来的 SSH 会话可能仍然正常，因为防火墙允许已经建立的连接继续通信。
但一旦退出，就可能再也无法登录。
因此，修改配置后测试一次全新的 SSH 登录，比单纯观察原连接是否正常更加重要。
四、两条 SSH 连接应该如何使用？
比较稳妥的操作流程如下。
第一步：建立操作连接。
打开终端 A：
ssh root@192.168.1.100这个窗口用于执行所有修改操作。
第二步：建立备用连接。
打开终端 B：
ssh -o ControlMaster=no \
-o ControlPath=none \
root@192.168.1.100这个窗口主要用于观察状态，不要随意关闭。
第三步：备份原始配置。
例如修改 SSH 配置前：
cp -a /etc/ssh/sshd_config \
/etc/ssh/sshd_config.bak如果修改的是防火墙、Netplan 等配置，也应该提前备份相应文件。
第四步：设置自动回滚。
对于高风险修改，可以通过 systemd 定时任务或其他机制，在指定时间后自动恢复原配置。
这样，即使 SSH 完全中断，也有机会由服务器本地执行恢复操作。
但自动回滚必须提前验证，确保不依赖当前 SSH 会话，并且恢复命令本身有效。
第五步：执行修改并验证。
通过操作窗口修改配置，然后使用一个新的 SSH 连接进行登录测试。
同时检查：
- SSH 是否可以重新登录
- IPv4、IPv6 网络是否正常
- 默认路由是否符合预期
- 防火墙是否允许必要的连接
- Tailscale 等虚拟网络是否正常运行
确认全部正常后，再取消自动回滚任务。
最后关闭备用窗口。
五、如果使用 Tailscale，还需要注意什么？
很多人会通过 Tailscale 管理自己的 VPS。
例如：
ssh root@100.64.0.103这种方式非常方便，不需要直接暴露服务器的公网 SSH 端口。
但这里存在一个容易忽略的问题。
如果操作窗口和备用窗口都通过同一个 Tailscale 地址连接，那么它们实际上依赖同一套虚拟网络。
一旦修改 Tailscale 路由、防火墙或者网络接口导致 Tailscale 失效，两个连接可能同时断开。
所以，如果准备修改 Tailscale 自身的配置，最好提前准备另一条不依赖 Tailscale 的管理通道。
例如服务器公网 SSH，或者云服务商提供的 VNC、Web Console。
其中，公网 SSH 必须提前确认可以正常登录，并做好密钥认证和访问控制。
真正可靠的备用通道，应该尽可能避免依赖正在修改的网络组件。
六、双 SSH 不等于绝对安全
需要特别强调，双 SSH 连接只是远程服务器运维中的一种保护措施。
它不能解决所有问题。
比如：
- 服务器网络接口被错误关闭
- 默认路由完全失效
- 防火墙同时阻止已有连接和新连接
- 服务器内核崩溃
- 系统重启后网络配置无法正常加载
这些情况下，即使同时建立十条 SSH 连接，也不一定有用。
更可靠的做法，是建立多层保护机制：
双 SSH 连接负责操作与验证，自动回滚负责故障恢复，带外控制台负责最后的应急处理。
对于重要服务器，最好同时具备这三种能力。
写在最后
建立两条 SSH 连接，并不是 Linux 服务器管理的强制要求，也不是什么复杂的高级技术。
它背后的核心思想很简单：不要让修改服务器的操作，轻易切断自己唯一的管理通道。
日常查看日志、维护普通应用，一条 SSH 连接完全够用。
但当我们准备修改 SSH、网络接口、默认路由、防火墙等关键配置时，多建立一条独立连接，提前设置自动回滚，并在修改后验证新的 SSH 登录，往往能够避免很多不必要的麻烦。
真正成熟的服务器运维，不只是考虑如何把配置修改成功，更要提前考虑：如果修改失败，我们还能不能恢复服务器？