SSH 连接不上怎么办？超时、拒绝连接与 Permission denied 排查
SSH 连接不上时，先保存完整报错、发生时间、目标 IP、端口和使用的账号。不要连续重置密码或反复重启服务器：连接超时通常尚未进入密码校验，而认证失败说明连接已经走得更远。下面按报错分支排查，示例地址与用户名都需要替换成自己的实际值。
第一步：确认连接的确实是目标服务器
核对交付信息中的公网地址、SSH 端口和系统默认账号。镜像可能使用普通管理员账号，不一定允许 root 登录。域名刚改过解析时，先比较域名解析结果与当前服务器 IP；有 AAAA 记录还要确认 IPv6 已正确配置，不能只检查 IPv4。
在本地终端执行一次带调试信息的连接：
ssh -vvv -o ConnectTimeout=10 -p 22 admin@203.0.113.10
-vvv 用于显示连接与认证进度，-p 指定端口。重点看最后停止在建立连接、密钥交换还是认证阶段，不必逐行解释所有输出。日志转给技术支持前，删去真实账号、内部地址和本地文件路径，绝不发送私钥。OpenSSH 客户端手册
连接超时：沿着访问路径逐层缩小范围
如果一直停在 Connecting to，最后出现 Connection timed out，优先检查地址是否正确、服务器是否运行，以及访问路径是否允许该 TCP 端口。能 ping 通不等于 SSH 端口开放；ping 不通也不能直接判断服务器宕机，因为 ICMP 可能被过滤。
若仅当前办公网络失败，可以从自己拥有或获准使用的另一个网络做一次对照。更换网络后成功，说明问题可能与本地出口、来源 IP 限制或这条网络路径有关。先核对当前公网出口是否发生变化，再调整来源白名单，不要把管理端口直接开放给所有地址。
平台提供独立控制台或救援入口时，可以从该入口检查系统；没有这类能力时，联系服务方确认实例与网络状态。系统防火墙和平台侧安全策略可能同时生效，两边都要检查实际端口及来源地址。每次只改一条有依据的规则，记录修改前的值。
Connection refused：检查是否真的有服务监听
拒绝连接通常表示目标或路径上的设备明确拒绝了请求，常见原因是端口写错、SSH 服务停止，或防火墙使用拒绝规则。进入服务器后先观察，不急于重启：
sudo ss -lntp
sudo systemctl status ssh --no-pager
sudo journalctl -u ssh --since "20 minutes ago" --no-pager
以上服务名适用于常见 Debian、Ubuntu 安装；其他发行版可能叫 sshd，应替换为实际单元名。查看 SSH 是否监听预期端口、是否只绑定回环地址，以及日志中有没有配置语法错误或主机密钥加载失败。使用容器、端口映射或跳板机时，还要核对连接终点与转发关系。
如果故障发生在刚修改配置之后，先恢复已备份的配置，再执行 sudo sshd -t 检查语法；部分系统需要使用 /usr/sbin/sshd 的完整路径。检查通过后，才按本机服务管理方式重新加载配置。sshd -t 不会替你验证网络规则和账号是否可登录。OpenSSH 服务端手册
Permission denied：对照账号与认证方式
出现 Permission denied (publickey) 时，网络和 SSH 握手通常已经建立，应转向账号、私钥选择和服务器公钥配置。确认当前账号与公钥安装账号一致，再明确指定私钥，避免客户端一次尝试过多无关密钥：
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 -p 22 admin@203.0.113.10
通过另一条可信管理入口检查该账号家目录下的公钥文件：公钥是否完整、是否错误换行、文件所有者是否正确，以及目录权限是否过宽。结合服务端同一时间的认证日志再修正，不要递归修改整个家目录权限，也不要为了测试打开 root 密码登录。密码认证失败还应检查账号锁定、过期和服务器是否允许这种认证方式。
改完后，用第二个会话验收
保留原有可用会话，在第二个终端重新连接，并确认账号能执行所需管理操作。新会话成功后再关闭旧会话；若失败，利用旧会话或独立管理入口恢复刚才的配置与规则。遇到主机指纹变化，应先通过可信渠道核对新指纹和重装记录，不能直接关闭主机密钥检查。
提交工单时附上报错阶段、测试时间与时区、来源网络、目标端口、一次脱敏调试日志和已完成的检查。这样的证据能区分网络不可达、服务未启动和认证不匹配，通常比“服务器连不上”的描述更快得到有效处理。