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 锁定变量，但得先确认运维流程能接受这个限制。