OpenSSH 不支持真正的热升级，所谓“平滑”实为通过 tmux/screen 会话保持、多端口双版本共存、负载均衡分批升级及客户端保活重连等组合策略，最大限度减少业务中断感知。
Linux 中 SSH 服务本身不支持连接状态下的平滑升级（即“热升级”），OpenSSH 的 sshd 进程一旦重启或替换二进制文件，所有现有 TCP 连接都会立即断开。所谓“平滑升级不中断连接”，实际是指在升级过程中尽量减少业务影响、避免人为误操作导致服务不可用，并保障已有会话的连续性——这需要组合策略，而非单靠配置。
核心思路是：不依赖 sshd 自身热更新，而是通过冗余、会话保持、客户端兜底三重保障来实现“感知不到中断”的效果。
✅ 1. 升级前确保已有连接可“挂起恢复”
SSH 协议层无法保留连接，但你可以让终端任务在断连后继续运行、重连后快速恢复：
-
用
tmux或screen包裹长期任务
登录后先执行：tmux new -s mysession # 或 screen -S mysession
所有命令在此会话中运行。即使 SSH 断开，进程仍在后台运行；重连后只需：
tmux attach -t mysession # 或 screen -r mysession
-
禁用 Shell 空闲退出（防 TMOUT 干扰）
检查并清除干扰：echo $TMOUT # 若输出数字（如 600），说明 10 分钟自动退出 unset TMOUT # 临时关闭 echo 'export TMOUT=0' >> ~/.bashrc # 永久关闭（谨慎用于生产环境）
✅ 2. 升级过程降低中断风险
OpenSSH 升级本质是替换 sshd 二进制和重启服务，关键控制点如下：
不要直接
kill -HUP或systemctl reload sshd
OpenSSH 不支持 reload 配置后热切换进程（reload实际等效于 restart，会 kill 当前进程）。必须restart，但可通过以下方式减小影响：-
分阶段部署（适用于多节点集群）
若为负载均衡后的多台 SSH 跳板机/堡垒机，可逐台维护：- 将某台从负载池摘除 → 升级 → 验证 → 重新加入
- 用户连接自动路由到其余正常节点，无感知。
-
保留旧版
sshd备份 + 多端口监听（临时双版本共存）
在升级前，修改/etc/ssh/sshd_config添加备用监听端口（如 2222），指向新编译的sshd二进制：Port 22 Port 2222
启动新版
sshd实例（不替换原进程）：/usr/local/bin/sshd -f /etc/ssh/sshd_config_new -p 2222
测试新版本功能、兼容性、密钥登录等无误后，再停旧版、切流量。
✅ 3. 客户端侧配合：自动重连 + 保活不掉线
虽然服务端升级必断连，但可大幅缩短“断—连—恢复”时间：
-
配置客户端保活（防止升级前因空闲被中间设备踢掉）
在~/.ssh/config中为关键主机启用心跳：Host prod-server HostName 192.168.1.100 User admin ServerAliveInterval 45 ServerAliveCountMax 3 ConnectTimeout 10
终端工具开启“断线重连”（仅 GUI 客户端）
如 MobaXterm、SecureCRT、Tabby 等支持自动重连（注意：务必关闭“自动填密码”，只用密钥认证，避免凭证泄露）。-
脚本化重连（慎用，仅限可信内网）
示例（需提前配好密钥免密）：while ! ssh -o ConnectTimeout=5 admin@prod-server -t 'tmux attach -t mysession 2>/dev/null || bash'; do sleep 3 done
⚠️ 不推荐用于公网或高安全要求环境（可能触发 fail2ban、堆积空闲连接）。
❌ 明确不可行的做法（常见误区）
-
sshd -t && systemctl reload sshd→ 不等于热升级，仍是重启 -
kill -USR2 $(pidof sshd)→ OpenSSH 不支持该信号，无效 - 修改
/etc/ssh/sshd_config后期望“动态生效” → 必须 restart 才加载新配置 - 以为
TCPKeepAlive yes能防止升级断连 → 它只维持 TCP 层存活，无法绕过进程终止
不复杂但容易忽略：真正的“平滑”，不在 SSH 本身，而在你如何设计运维流程、保护用户会话、控制升级节奏。
