TMOUT仅作用于shell层输入计时，无法感知网络中断或客户端假死；ClientAliveInterval与ClientAliveCountMax在sshd层通过加密心跳探测连接真实性，二者必须配合使用才能可靠防断连。
必须同时配置 TMOUT 和 ClientAliveInterval + ClientAliveCountMax，缺一不可。只设一个，SSH 空闲断连大概率失效。
为什么单靠 TMOUT 无法可靠断开 SSH 空闲连接
TMOUT 是 shell 层变量，只在用户有键盘输入时计时；一旦网络中断、客户端休眠或终端假死，sshd 进程仍认为连接活跃，TMOUT 根本不触发。常见现象包括：
- 笔记本合盖再打开，SSH 终端卡住但没退出，
echo $TMOUT仍有值 - 执行
tail -f /var/log/messages后静默等待，TMOUT不计时（全屏程序接管 stdin） - 图形终端（GNOME Terminal、Konsole）完全忽略
TMOUT
所以它只管“用户有没有敲键盘”，不管“连接还通不通”。生产环境不能只依赖它。
ClientAliveInterval 和 ClientAliveCountMax 怎么配才有效
这两个参数在 /etc/ssh/sshd_config 中协同工作：前者控制心跳发送频率（秒），后者控制允许丢失的心跳次数。总空闲容忍时间 = ClientAliveInterval × ClientAliveCountMax。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 推荐组合：
ClientAliveInterval 300（5 分钟发一次） +ClientAliveCountMax 3（最多丢 3 次）→ 实际超时 15 分钟 - 避免设
ClientAliveCountMax 0：这会让 sshd 在第一次心跳无响应时立即断连，极易误杀正常连接 - 必须取消注释：检查配置文件里这两行前面不能有
#，且不能写成ClientAliveInterval=300（等号是错的） - 改完必须重启服务：
sudo systemctl restart sshd，reload有时不生效
如何验证配置已真正起作用
别只看 echo $TMOUT 或 sshd -t 配置语法检查——那只是“写对了”，不是“跑对了”。真实验证要分两步：
- Shell 层验证：新 SSH 登录后，执行
unset TMOUT，然后静默等待设定时间（如 15 分钟），观察是否被踢出。若未退出，说明ClientAlive没生效 - 网络层验证：用另一台机器 SSH 连上，执行
sudo ss -tnp | grep :22，确认 ESTABLISHED 连接存在；然后拔掉网线或关掉客户端，等超过ClientAliveInterval × ClientAliveCountMax时间，再查连接是否消失 - 注意：
systemd-logind可能干扰测试——如果系统启用了 IdleAction（如 lock 或 terminate），它会抢在 sshd 前干掉会话
容易被忽略的权限与兼容性细节
很多配置看似正确却在特定账号下失效，根源常在这些地方：
-
root用户可能绕过/etc/profile：某些发行版中root默认读~/.bashrc而非/etc/profile，需单独检查其配置文件 -
sudo -i或su -会重载目标用户环境：若目标用户家目录里有unset TMOUT，全局设置就被清空 -
tmux或screen会话不继承TMOUT：它们自身是独立进程，需在会话内手动设export TMOUT=900，或依赖 SSH 层保活 - 某些容器或最小化系统（如 Alpine）默认用
ash而非bash：TMOUT在ash中无效，只能靠ClientAlive*保底
最稳妥的做法是：服务端 ClientAlive* 必配，TMOUT 作为补充；高安全场景再加 readonly TMOUT 锁定变量，但得先确认运维流程能接受这个限制。
