华为云 ECS 连不上？SSH 排查清单：先分清是网络不通还是认证失败

为什么先分两类

ECS 上不去，90% 的人第一反应是「密码错了」或「安全组没开」，然后开始乱试。其实只要先看一眼报错，排查范围立刻缩小一半：

记住这个顺序：先网络，后认证。网络不通的时候调密码是纯浪费。

第一层：网络是否可达

1. 弹性公网 IP 绑定了吗

最常见的低级问题：实例建好了，但 EIP 没绑，或者绑在了另一台机器上。控制台实例列表确认「弹性公网IP」一栏有值，且和你 ssh 的目标一致。

2. 安全组入方向放通 22 了吗

安全组是白名单机制，默认不放通任何入方向端口。需要一条规则：

方向：入方向
协议端口：TCP 22
源地址：你的出口 IP/32（不要图省事写 0.0.0.0/0）

改完规则立即生效，不用重启实例。

坑：改的是实例绑定的那个安全组，不是账号下随便一个安全组。一台 ECS 可以绑多个安全组，规则取并集，容易改错对象。

3. 系统内部防火墙

安全组放通了，系统里还有一层。云上镜像常见两种情况：

# firewalld（CentOS / openEuler 系）
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=22/tcp --permanent && sudo firewall-cmd --reload

# ufw（Ubuntu / Debian 系）
sudo ufw status
sudo ufw allow 22/tcp

还有一种更隐蔽的：iptables 里被手工加了 DROP 规则，ufw status 却显示 inactive。

4. 端口到底通不通

用 nc 或 telnet 从本地打一下，比反复重试 ssh 高效得多：

nc -zv -w 5 <EIP> 22

• succeeded → 网络层没问题，直接跳到第二层
• timed out → 包被丢，回去查安全组/防火墙
• refused → 端口没监听，登录控制台查 sshd

第二层：认证为什么失败

5. 密钥对和镜像是否匹配

创建实例时如果选了密钥对，镜像里注入的是公钥。之后在本地把私钥搞丢、或者换了一台电脑，就只能走控制台重置。

判断方法：ssh -i key.pem -v root@<EIP>，看详细日志里有没有 Offering public key、Server accepts key。如果连 Offering 都没有，说明私钥没被加载——先查文件权限。

6. 私钥权限必须收紧

OpenSSH 对私钥权限很敏感，权限过宽会直接拒绝使用：

chmod 600 key.pem

Windows 上如果用 WSL 或 Git Bash，注意不要把文件放在挂载的 NTFS 目录下——权限位会被抹平，报 bad permissions。把 key 拷到 WSL 的 home 目录再 chmod 600。

7. 用户名不是想当然的

不同镜像的默认用户不同：

用户名错会表现为 Permission denied，但日志里能看到 Authentications that can continue 只有 publickey——说明服务器根本不认你给的身份。

8. 密码登录被镜像默认关闭

很多公共镜像默认 PasswordAuthentication no，只能密钥登录。要开密码登录，得先能进去（用密钥或 VNC），再改配置：

sudo vi /etc/ssh/sshd_config
# 改为：
# PasswordAuthentication yes

sudo systemctl restart sshd

改完先别断开当前会话，另开一个窗口验证能登录再关——否则配错就彻底进不去了。

兜底手段：VNC 控制台

网络层和认证层都卡死时，用控制台的 VNC 登录（相当于接了个显示器）。它走的是平台内部通道，不依赖 EIP、安全组和 sshd 配置，是最后的救命入口。

进去之后能做的：

• 查 systemctl status sshd，确认服务活着
• 查 ss -tlnp | grep 22，确认监听地址不是 127.0.0.1
• 查 cat /var/log/secure（或 /var/log/auth.log），看认证失败的真实原因
• 重置密码、重新绑定密钥对

一套可以照着跑的排查顺序

1. ping <EIP>                    → 通不通（不通先查 EIP / 安全组 ICMP）
2. nc -zv -w 5 <EIP> 22          → 端口通不通
3. ssh -i key.pem -v user@<EIP>  → 看认证协商到哪一步
4. 控制台 VNC 登录               → 看 sshd 状态与日志
5. 改 sshd_config / 重置密钥     → 修好后另开窗口验证

按这个顺序走，基本不会出现「改了五处配置，不知道是哪一处起的作用」的情况——每一步都有明确的判断信号。

几个容易忽略的点

• 安全组规则改完不生效：确认改的是实例绑定的安全组，且没有更高优先级的拒绝规则
• Connection timed out 但 ping 得通：ICMP 和 TCP 走不同规则，ping 通不代表 22 通
• 能 ping 通却 refused：sshd 没起来，或监听在非 22 端口（改过 Port 的机器很常见）
• 改完 sshd 配置把自己锁在外面：这是最经典的翻车方式，务必保留一个已登录会话做验证
• EIP 计费：按带宽或按流量计费，排查期间挂着不用的 EIP 也在产生费用，完事记得释放

小结

SSH 连不上本质只有三种可能：包到不了（网络）、端口不在听（服务）、身份不被认（认证）。先看报错归类，再用 nc 和 ssh -v 两个命令定位到具体层，比对着控制台逐项怀疑快得多。

安全组和 sshd 配置这两处，改之前先想清楚「改错了怎么回去」——留一个活动会话，是所有远程运维操作的前提。