云服务器重装后SSH连不上：我从外到内排查了四层才找到原因

一、故障现象

一台云服务器重装成 Debian 12 之后，我按以前的习惯打开终端连 SSH，结果直接超时。用控制台里显示的地址和端口反复试了几次，又换了密码登录，都不行。

一开始我以为是自己记错了密码，这是重装后最常见的错觉。其实重装系统后的 SSH 故障，十有八九不是单一原因，而是初始化没走完留下的几个问题叠在了一起。这篇文章把我这次完整的排查顺序记下来，下次再遇到同类问题，照着从外到内查一遍，基本不会漏。

二、排查原则：从外到内，不要一上来就改配置

SSH 连不上，链路其实只有四层：1. 云平台层：端口映射、安全组、防火墙有没有放行；2. 网络层：服务器网卡有没有正常起来，有没有拿到正确 IP；3. 服务层：sshd 服务有没有在运行、有没有监听端口；4. 账号层：登录的账号是否存在、是否被锁定、是否允许登录。

很多人一遇到问题就去改 /etc/ssh/sshd_config，改完还是连不上，因为问题根本不在那一层。下面是我这次实际踩到的四个坑，刚好一层一个。

三、第一层：控制台的端口映射还没建好

通过云厂商控制台的 VNC / 远程连接先登进系统（SSH 不通时这是唯一的入口），但在进系统之前，先看控制台本身。

这台机器用的是 NAT 方式，公网地址要映射到内网的 22 端口。重装之后我发现原来的映射已经没了，外网连的那个端口根本没有转发到这台机器上，自然怎么试都超时。处理方法很简单：在控制台重新建立端口映射，公网端口转发到内网 IP 的 22 端口，同时确认安全组里这个公网端口是放行状态。

心得：凡是“连接超时”（timeout），先查网络和映射，不要先怀疑密码；密码错的表现是能连上、但认证被拒绝（permission denied），两者完全不是一回事。先分清这两种报错，能少走一半弯路。

四、第二层：网卡配置里残留了旧 MAC 地址

映射建好后还是不通。进系统后执行：

ip aip route

发现网卡根本没有拿到预期的内网 IP。继续检查网络配置，Debian 云镜像常用 netplan 管理网络：

cat /etc/netplan/*.yaml

问题就在这里：配置文件里写死了重装之前的 MAC 地址，并用它来匹配网卡。重装后虚拟网卡的 MAC 已经变了，配置匹配不上，网卡就没被正确配置，IP、网关全都没生效。

把配置里绑定的 MAC 改成当前网卡的实际 MAC（用 ip link 查看），或者去掉按 MAC 匹配的那一行、改为直接按网卡名匹配，然后执行：

netplan applyip a

这次网卡正常拿到 IP，ping 网关也通了，网络层才算真正恢复。心得：云服务器重装、更换实例、迁移之后，凡是配置里写死 MAC、UUID 这类硬件标识的地方，都是重点嫌疑对象。

五、第三层：sshd 缺主机密钥，服务根本没起来

网络通了之后，我以为这下能连了，结果还是拒绝。检查服务状态：

systemctl status sshss -tlnp | grep 22

ss 的结果里根本没有 22 端口在监听，systemctl 里 sshd 也处于失败状态。看日志定位：

journalctl -u ssh -els -l /etc/ssh/

日志里明确报缺少主机密钥（host key）。原因是这次重装用的模板初始化没有完整跑完，首次启动时本应自动生成的 /etc/ssh/ssh_host_* 密钥文件不存在，sshd 没有密钥就拒绝启动。补生成全部主机密钥并重启服务：

ssh-keygen -Asystemctl restart sshss -tlnp | grep 22

看到 22 端口重新处于 LISTEN 状态，服务层这一关才算过。注意 ssh-keygen -A 生成的是服务器的主机密钥，不是用户的登录密钥，两者不要混淆。

六、第四层：root 账号从未设过密码，而且处于锁定状态

服务起来后从外网测试，终于能连到登录提示了，但密码怎么输都是 permission denied。回到控制台里检查账号状态：

passwd -S rootgrep root /etc/shadow

结果显示 root 处于锁定状态。原因还是初始化未完成：这个镜像里的 root 从来没有真正设置过密码，影子文件里对应字段是锁定标记，所以不是“我密码记错了”，而是这个账号根本没有一个可用的密码可以登录。

在控制台里为 root 重新设置密码，并确认 sshd 配置允许密码登录用于首次接入：

passwd rootgrep -E 'PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_configsystemctl restart ssh

再次从自己的电脑用 SSH 连接，这次一次成功，外部连接验证通过。

需要强调的是，这只是为了把首次接入打通的临时做法。能登录之后，我立刻做了两件收尾：第一，配置密钥登录，上传公钥到 ~/.ssh/authorized_keys 并确认密钥能免密登录；第二，在确认密钥登录稳定后，再考虑关闭密码登录、关闭 root 直接登录，改用普通用户加 sudo。先打通、再收紧，顺序不要反过来，否则很容易把自己锁在门外。

七、复盘：一张重装后的检查清单

这次故障表面看是“SSH 连不上”，实际上是端口映射缺失、网卡 MAC 残留、sshd 缺密钥、root 被锁定四个问题叠加。任何一个单独存在都会表现为连不上，只修其中一个就会误以为“修了还没好”。

以后每次重装我都照这个顺序查：1. 端口映射与安全组是否放行（云控制台）；2. 网卡是否拿到正确 IP（ip a、ip route）；3. 网络配置是否残留旧 MAC / UUID（cat /etc/netplan/*.yaml）；4. sshd 是否在监听（ss -tlnp | grep 22）；5. sshd 日志与主机密钥是否完整（journalctl -u ssh、ls /etc/ssh/）；6. 登录账号是否锁定（passwd -S root）；7. 从外网真实连接验证一次（自己电脑的 SSH 客户端）。

特别提醒最后一步：一定要从外网、用平时工作的方式真实连一次才算修好。只在控制台里看到服务是 active 就宣布完成，很可能漏掉映射和安全组那一层，我这次就是在控制台里“看着都正常”、外网却死活连不上。

八、总结

云服务器重装后的 SSH 故障，排查的关键不是记得多少命令，而是顺序：先分清超时还是认证失败，再从云平台、网络、服务、账号一层层往里查，每修一层就验证一层。模板初始化不完整是这类问题的常见根源，网卡标识、主机密钥、初始账号这三处，是重装之后最值得先看一眼的地方。把这套顺序固化成清单之后，重装就不再是碰运气了。