SSH连接超时需先区分“连不上”与“连上就断”：前者查网络、端口、防火墙、sshd状态；后者多为空闲超时，应配置客户端ServerAliveInterval/ServerAliveCountMax和服务端ClientAliveInterval/ClientAliveCountMax参数，并检查中间设备NAT老化。
SSH 客户端连接超时，通常不是“连不上”，而是“连上又断”或“卡住不动”。关键要先分清是连接建立阶段失败，还是连接建立后空闲断开——两者的排查路径完全不同。
看日志，快速定位卡在哪个环节
别凭感觉猜，用 ssh -v user@host 手动复现一次：
- 如果几秒内就报 Connection timed out 或直接卡在
debug1: Connecting to ...→ 问题出在网络层或服务端未监听 - 如果能走到
debug1: Authentication succeeded，但之后很久没反应或突然断开 → 很可能是空闲超时或中间设备回收连接 - 如果出现 Write failed: Broken pipe 或 Connection closed by remote host → 基本锁定为服务端主动断连，和保活配置强相关
检查网络与服务端基础状态
连接超时的第一道关卡，永远是通不通、听不听：
- 本地执行
ping 服务器IP和nc -zv 服务器IP 22：能 ping 通但 nc 超时，说明网络可达但端口被拦（防火墙或云安全组） - 登录服务器，运行
ss -tlnp | grep :22：确认 sshd 确实在监听0.0.0.0:22（不是只有127.0.0.1:22） - 查服务状态：
systemctl status sshd，确保是 active (running)；若非活跃，先sudo systemctl start sshd - 云服务器务必检查安全组规则：入方向必须显式放行 TCP 22（或你自定义的端口），源 IP 可先设为
0.0.0.0/0快速验证
区分“连不上”和“连上就断”
这是最易混淆也最关键的判断点：
- 连不上（Connection timed out / No route to host）：重点查网络链路、sshd 是否运行、端口是否监听、防火墙/安全组是否放行
- 连上就断（Broken pipe / Connection closed）：基本是空闲超时，需同步调整客户端和服务端保活参数
- 客户端侧加心跳：
~/.ssh/config中添加： Host *
ServerAliveInterval 60
ServerAliveCountMax 3
TCPKeepAlive yes - 服务端侧加固：
/etc/ssh/sshd_config中设置： ClientAliveInterval 60
ClientAliveCountMax 3
TCPKeepAlive yes
改完执行sudo systemctl reload sshd
注意几个隐蔽但高频的坑
很多超时问题其实卡在细节上：
- 私钥路径含中文、空格或用了相对路径 → Navicat 或 ssh 命令会静默失败，务必用绝对路径且权限为
600 - 改过 SSH 端口（比如设成 2222）但客户端没加
-p 2222→ 默认连 22，必然超时 - 服务端
sshd_config中AllowTcpForwarding no→ Navicat 的 SSH 隧道会卡在“Connecting to SSH host”，即使密码/密钥都对 - SELinux 或 AppArmor 启用状态下，可能拦截 SSH 连接行为，可临时设为 permissive 模式验证是否为此原因
