Ubuntu VPS 的 SSH 连接错误排查
SSH 连不上 Ubuntu VPS 时，先根据报错判断发生在哪个阶段。下面分别检查网络、监听服务、用户认证和主机身份，并在排查过程中保留原有可用连接。
VPSuntu · 更新： · 约 5 分钟阅读
本页目录
保存一次失败记录，留住恢复入口
保留所有成功的 SSH 会话，找到服务商的恢复控制台。客户端命令在自己电脑的 Linux、macOS 或 WSL 中运行；服务器命令则通过已有会话或经过认证的恢复控制台执行，不要贴到本机终端。
将文档地址 203.0.113.10、ubuntu、端口 22 和私钥路径替换成实际值。先查看客户端最终采用的配置，再进行一次全新连接：
ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10检查 hostname、user、port、identityfile 和代理设置。第二条命令仅对这次尝试禁用连接复用。记下时间和最后的错误。如果出现新主机密钥提示，按后面的身份核验步骤处理。分享调试输出前遮蔽用户名、地址和路径，绝不要分享私钥。
按报错阶段选择排查方向
小屏幕上可左右滚动表格，查看完整内容。
| 报错或阶段 | 说明什么 | 下一步 |
|---|---|---|
| 建立连接前 Connection timed out | TCP 连接没有完成 | 地址、路由、防火墙和实例状态 |
| Connection refused | 该地址和端口主动拒绝 | 目标端口、监听服务和拒绝规则 |
| Permission denied (publickey) | 已经到达 SSH 认证阶段，但凭据不被接受 | 用户名、发送的密钥和服务器策略 |
| REMOTE HOST IDENTIFICATION HAS CHANGED | 收到的主机身份与保存记录不同 | 继续连接前通过可信来源核对主机密钥 |
这些现象只能缩小范围，不能直接断定唯一原因。如果超时前已经出现 Connection established，应继续检查 SSH 握手和服务器日志，不能认定所有数据包都被拦截。
超时：沿预期网络路径检查
对比 ssh -v 显示的目的地与服务商面板当前地址。使用域名时，旧 DNS 记录或另一个 IPv6 地址可能把请求送往别处。确认该 VPS 应通过公网、VPN 还是跳板机访问。
确认实例运行且存在正确公网路由。在服务商防火墙核对实际 SSH 目标端口和当前公网来源地址；家用网络地址可能已经变化，而 /32 白名单仍是旧值。通过控制台也要检查虚拟机内部防火墙。
Oracle Cloud 的安全列表、NSG、路由和内部防火墙都要检查。保留镜像原有规则，安装 UFW 或清空 iptables 不是诊断方法。网络布局见Oracle Ubuntu 创建教程。单凭 ping 失败也不能断定 SSH 不可用。
连接被拒绝：检查服务是否监听
拒绝连接并不能证明对方就是预期的 VPS。确认实例身份与端口后，通过现有会话或恢复控制台，在服务器执行以下只读检查：
systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager查看预期地址和端口的监听状态，并把日志时间与你的连接尝试对应起来。Ubuntu 可能采用 socket 激活机制；如果 ssh.socket 正在监听，ssh.service 显示未运行并不足以证明 SSH 不可用。
sshd -t 检查配置与主机密钥有效性，不会启动守护进程。没有输出且成功退出，不代表网络可达。若有报错，先定位具体文件或配置项，再考虑重新加载，不要盲目重启。
公钥认证失败：核对账号与实际发送的密钥
使用服务商给出的初始用户名，或已经创建的管理员账号，不要猜用户名。在客户端调试输出中找出实际发送的密钥指纹。为减少 agent 发送无关密钥，可在本机重试：
ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10配置中的 IdentityFile 仍可能生效，请检查 ssh -G。如果客户端提示私钥不可读或权限过宽，先修正本机文件访问，再调整服务器。
在服务器查看目标账号与已授权公钥。本例假设主目录为 /home/ubuntu，应替换为 getent 返回的实际目录：
getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys将授权密钥指纹与客户端发送的指纹比较，并查看 journal 中的归属、权限或账号策略错误。不使用默认路径时，检查 AuthorizedKeysFile、包含的配置片段与 Match 规则。服务商管理的密钥服务也可能改变认证方式。保留已有公钥，不要禁用 StrictModes 或开放密码登录来掩盖问题。
主机密钥变化：先解释原因再连接
重建实例或重新分配 IP 都可能改变主机密钥；意外变化也可能表示连接了错误端点，甚至存在拦截。通过已经登录的服务商面板确认实例 ID，以及是否确实安排过重建。
从可信控制台进入虚拟机，查看与客户端提示算法相同的公开主机密钥。Ed25519 示例：
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256把 SHA256 指纹与客户端警告核对。这里是服务器主机密钥，不是登录密钥，也不是服务商控制台网关的密钥。确认更换合法后，可能需要更新该服务器的保存条目；先备份文件，保留无关条目。不要整体删除 known_hosts 或绕过校验。如果身份变化仍无法解释，应停止连接并继续调查。
用全新会话验证具体修正
只修正已经定位的地址、账号、密钥、特定网络规则或配置错误。修改服务器期间保留独立访问入口，应用前验证 SSH 配置。更换端口还可能涉及 socket 激活设置，并非重启服务就足够。
禁用连接复用后重复最初尝试，确认新的登录进入正确账号，所需 sudo 权限也正常。旧会话没有断开不算验证通过。记录原因和修改内容；若部署因此中断，再返回Ubuntu VPS 配置教程。
常见问题
修复 SSH 是否需要重装 Ubuntu？
先排查。地址、用户名或密钥错误不需要重装系统，而重装可能损坏数据。完全失去访问时，使用服务商提供的恢复流程。
控制台能登录，为什么 SSH 还不通？
它们走不同路径。SSH 仍需要虚拟机服务监听、账号认证和网络规则全部允许连接。