SSH连不上服务器怎么办？按报错排查端口、密钥与服务

先说结论：SSH 连不上时，先保存完整报错，再按“地址与网络 → TCP 端口 → 安全组/防火墙 → sshd 服务 → 用户与密钥 → 主机指纹”逐层排查。Connection timed out、Connection refused、Permission denied 和 REMOTE HOST IDENTIFICATION HAS CHANGED 指向不同层，不能靠重启、重装或把 22 端口开放给全网碰运气。

第一步：保存准确报错与连接参数

在本地终端使用实际用户、端口和密钥执行详细日志：

ssh -vvv -o ConnectTimeout=10 -p 22 -i ~/.ssh/id_ed25519 user@203.0.113.10

OpenSSH ssh 手册说明，-v用于输出连接、认证和配置调试信息，最多可使用三个 v。日志可能包含用户名、地址和路径，分享给工单前应脱敏；绝不能上传私钥、密码或会话令牌。

第二步：核对实例、IP、用户和端口

• 实例是否处于运行状态，是否刚重装、重启、冻结、到期或更换 IP；
• 连接的是当前公网 IP 或正确 DNS，而不是内网、旧地址或错误的 AAAA；
• Linux 镜像默认用户可能是 root、ubuntu、debian 等，以镜像说明为准；
• SSH 是否仍使用 22，还是控制台/配置中记录的自定义端口；
• IPv4 与 IPv6 是否分别可达，可用 ssh -4 或 ssh -6定位。

不要根据第三方教程猜“服务商一定使用随机端口”。订单、实例详情、交付邮件和现有配置才是证据。

第三步：从客户端测试 TCP，而不只看 Ping

Ping 使用 ICMP，SSH 使用 TCP。Ping 被禁不代表 SSH 不通，Ping 通也不代表目标端口开放。

# macOS / Linux
nc -vz -w 5 203.0.113.10 22

# Windows PowerShell
Test-NetConnection 203.0.113.10 -Port 22

再用手机热点或另一家网络复测。如果只有一个来源失败，应检查公司出口、运营商、本地防火墙、访问白名单或 Fail2ban；如果所有来源都失败，再检查服务器侧。整机可达性流程见云服务器 IP 连接不上排查。

第四步：检查云安全组和系统防火墙

云安全组与操作系统防火墙是两层控制，目标 TCP 端口必须在两层都允许。管理端口优先只允许管理员固定公网 IP、办公出口、堡垒机或企业 VPN 地址段，不要为了排查长期设置 0.0.0.0/0 或 ::/0。

在控制台连接中检查：

# Ubuntu / Debian 常见
sudo ufw status verbose

# RHEL 系常见
sudo firewall-cmd --list-all

# 查看内核规则（按系统实际工具）
sudo nft list ruleset

规则设计和来源限制见云服务器安全组配置指南。不要通过停用整个防火墙来“证明问题”，应读取命中规则和日志，添加范围最小、可回退的临时规则。

第五步：从云控制台检查 sshd

使用供应商提供的 Web Console、VNC、串口控制台或救援模式进入系统。不同发行版的服务单元可能叫 ssh 或 sshd：

sudo systemctl status ssh
sudo systemctl status sshd
sudo ss -lntp
sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication|permitrootlogin)'

确认 sshd 正在运行、监听预期端口和网卡。只监听 127.0.0.1 或错误的 IPv6/IPv4 地址时，外部无法连接。修改 sshd_config 前保留控制台和当前 SSH 会话，备份配置，并先执行：

sudo sshd -t

只有语法检查成功才 reload 对应服务，再从第二个终端测试新会话；新会话成功前不要关闭原会话。不要直接重启整台 VPS。具体配置项以OpenSSH sshd_config 手册和当前发行版文档为准。

第六步：按 Permission denied 排查认证

先从错误末尾确认服务端接受哪些认证方式。公钥登录重点检查：

• 本地 -i 指向正确私钥，不要把 .pub 公钥文件当私钥；
• 目标用户正确，公钥在该用户的 ~/.ssh/authorized_keys 中；
• 目录和文件归目标用户所有，~/.ssh 通常不应允许其他用户写入；
• SELinux、集中账号、AuthorizedKeysCommand 或云初始化是否改变了公钥来源；
• 服务端是否通过 Match 块、AllowUsers、PermitRootLogin 等限制该用户；
• 客户端是否被 ssh-agent 中的其他密钥干扰。

可显式限制客户端只尝试指定密钥：

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 -p 22 user@203.0.113.10

不要为了定位公钥问题临时向公网开启密码登录，更不要关闭现有密钥认证。若业务确需密码认证，应在受限来源、强密码、速率限制和监控下单独评估。

第七步：查看服务端日志

# systemd 日志
sudo journalctl -u ssh --since "30 minutes ago"
sudo journalctl -u sshd --since "30 minutes ago"

# 常见文件日志，实际路径因发行版而异
sudo tail -n 100 /var/log/auth.log
sudo tail -n 100 /var/log/secure

关注无效用户、公钥权限、认证策略、PAM、账号锁定、磁盘满、内存不足、Fail2ban 和连接速率限制。日志没有任何对应连接记录，通常说明请求还未到 sshd，应回到网络、安全组和防火墙层。

主机指纹变化怎么处理？

REMOTE HOST IDENTIFICATION HAS CHANGED 是防止中间人攻击的重要告警，不能看到提示就直接删除 known_hosts。先通过云控制台或另一条可信渠道查看服务器主机公钥指纹：

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

只有确认实例确实重装、更换并且新指纹匹配后，才从本地移除该主机的旧记录并重新连接。OpenSSH 文档也说明，主机身份变化时客户端会警告并限制认证以防冒充。

完全失联时的恢复顺序

1. 保存故障时间、IP、端口、错误、客户端网络和最近变更；
2. 使用控制台连接，不先重装系统；
3. 检查磁盘、内存、网络配置、sshd 状态和防火墙日志；
4. 回退最近的 SSH、安全组、网络或系统变更；
5. 控制台不可用时，询问是否支持救援系统或挂载系统盘修复；
6. 涉及宿主机或平台网络时，携带证据提交支持工单；
7. 恢复后补监控、备用管理员密钥和变更记录。

强制重启可能丢失内存数据或扩大文件系统问题，应先按服务器卡住与重启前检查评估。

修复后的安全验收

• 从授权网络新建 SSH 会话成功，原有会话也正常；
• 不再需要的临时规则、临时账号和调试日志已撤回；
• 安全组只允许必要来源和实际端口；
• 公钥、主机指纹、账号权限和日志符合预期；
• 密码登录、root 登录和端口转发按业务最小化；
• 暴力尝试、服务停止和资源耗尽已有告警；
• 备用控制台与恢复步骤经过一次演练。

什么时候才需要新建服务器？

端口、密钥和 sshd 配置问题通常不需要换 VPS。只有系统严重损坏且无法安全恢复、旧系统停止维护，或现有节点网络长期不满足业务时，才先备份数据并验证恢复，再迁移。需要隔离的恢复或替换环境时，可到萤光云 VPS 产品页核对当前地域、系统和配置，并按VPS 配置选择指南确定资源。

常见问题

Ping 通但 SSH 超时是什么原因？

ICMP 可达不代表 TCP 端口可达。优先检查目标端口、安全组、防火墙、监听地址和客户端来源限制。

改 SSH 端口能防攻击吗？

可减少部分自动扫描噪声，但不能替代来源限制、密钥认证、最小权限、更新和监控。

重装后为什么提示主机密钥变化？

重装通常会生成新主机密钥。必须先通过可信控制台核对指纹，再更新本地记录。

相关推荐

• 服务器端口不通排查
• VPS 常用端口与开放原则
• 新服务器安全加固清单
• 站点与服务器监控指南