今天遇到一个比较容易让人紧张的问题：服务器突然 SSH 连接不上了。

网站还能不能访问先不说，最麻烦的是服务器远程进不去。很多人遇到这种情况，第一反应就是服务器是不是宕机了，或者系统是不是坏了。

但这次排查下来发现，服务器本身并没有坏，真正的问题出在防火墙和SSH端口上。

一、问题出现时的表现

当时的情况是这样的：

• 使用 SSH 工具连接服务器失败

• 连接一直超时

• 输入账号密码的界面都进不去

• ping 服务器 IP 有响应

• 网站访问有时正常，有时变慢

• 控制台显示服务器是运行状态

从这些表现来看，服务器不是完全宕机。

因为如果服务器真的关机或者网络完全断开，ping 通常也会异常，控制台状态也可能不正常。

所以这次的重点不是服务器是否开机，而是 SSH 服务或者端口是否能正常访问。

二、第一步：先判断服务器是否在线

我先从本地电脑测试服务器 IP 是否能连通。

ping 服务器IP

结果是可以 ping 通的。

这说明服务器网络大概率是通的。

然后我又尝试连接 SSH：

ssh root@服务器IP

结果提示连接超时。

这里要注意，如果是密码错误，通常会提示输入密码或者认证失败。

但如果是连接超时，说明请求可能根本没有到达 SSH 服务，或者中间被防火墙拦住了。

三、第二步：检查SSH端口是否开放

默认情况下，Linux 服务器 SSH 端口一般是 22。

我在本地测试端口连通性。

telnet 服务器IP 22

如果没有 telnet，也可以用：

nc -vz 服务器IP 22

测试结果显示 22 端口连接失败。

这说明问题方向更清楚了：

服务器在线，但 SSH 端口不通。

这种情况一般有几种可能：

• SSH服务没有运行

• SSH端口被改了

• 系统防火墙拦截了

• 云平台安全组没有放行

• 机房网络策略限制了端口

四、第三步：通过VNC进入服务器

因为 SSH 进不去，我只能通过云平台提供的 VNC 控制台进入服务器。

进入 VNC 后，先检查 SSH 服务状态：

systemctl status sshd

结果显示 SSH 服务是正常运行的。

这一步很关键。

如果 sshd 服务没运行，那问题就是 SSH 服务本身。

但现在 sshd 是正常的，说明问题更可能出在端口监听或防火墙规则上。

五、第四步：确认SSH监听端口

继续查看服务器当前监听的 SSH 端口。

ss -lntp | grep ssh

结果发现 SSH 并不是监听在 22 端口，而是监听在另外一个端口。

这时我才想起来，之前为了安全，服务器 SSH 端口曾经修改过。

但是本地连接的时候还是使用了默认 22 端口，所以一直连接不上。

如果 SSH 端口修改过，正确连接方式应该是：

ssh -p 端口号 root@服务器IP

不过我测试后发现，使用新端口仍然连接失败。

这说明除了端口写错之外，防火墙可能也没有放行新端口。

六、第五步：检查系统防火墙规则

继续在服务器里查看防火墙状态。

如果是 firewalld，可以使用：

firewall-cmd --state

查看已开放端口：

firewall-cmd --list-ports

结果发现新 SSH 端口没有在放行列表里。

也就是说：

SSH 服务确实在监听新端口，但系统防火墙没有放行这个端口。

外部连接请求进来后，直接被防火墙拦截了。

七、问题真正原因

这次 SSH 突然连接不上的真正原因是：

• SSH 默认端口已经修改

• 本地仍然使用 22 端口连接

• 新端口虽然被 SSH 服务监听

• 但系统防火墙没有放行新端口

• 导致外部无法通过 SSH 连接服务器

所以这次并不是服务器坏了，也不是账号密码错误。

而是端口和防火墙规则没有对应上。

八、实际修复过程

确认原因后，我开始处理。

1. 放行新的SSH端口

firewall-cmd --zone=public --add-port=端口号/tcp --permanent

2. 重新加载防火墙规则

firewall-cmd --reload

3. 再次确认端口是否放行

firewall-cmd --list-ports

确认新端口已经出现在列表里。

4. 本地重新连接服务器

ssh -p 端口号 root@服务器IP

这次 SSH 正常连接成功。

九、还需要检查云平台安全组

这里还有一个很容易被忽略的地方。

如果服务器是在云平台上，还要检查安全组规则。

即使系统防火墙放行了端口，如果云平台安全组没有放行，也一样连接不上。

所以我又检查了云平台安全组：

• 入方向规则是否放行 SSH 端口

• 协议是否为 TCP

• 授权对象是否正确

• 是否只允许了某个固定IP访问

如果安全组限制比较严格，本地IP变化后，也可能导致 SSH 连接失败。

这种情况并不是服务器问题，而是访问来源不在放行范围内。

十、恢复后的检查

SSH 恢复后，我没有马上结束，而是又做了几项检查。

1. 检查 SSH 服务是否开机自启

systemctl enable sshd

2. 检查 SSH 服务状态

systemctl status sshd

3. 检查端口监听

ss -lntp | grep ssh

4. 检查防火墙规则

firewall-cmd --list-ports

确认这些都正常后，才算真正处理完成。

十一、这次问题的经验总结

这次 SSH 连接不上，其实不是一个复杂故障。

但它很容易让人误判为服务器宕机。

以后遇到 SSH 连接失败，可以按这个顺序排查：

1. 先看服务器是否在线

2. 再测试 SSH 端口是否通

3. 通过 VNC 进入服务器

4. 检查 sshd 服务状态

5. 检查 SSH 实际监听端口

6. 检查系统防火墙

7. 检查云平台安全组

8. 最后再重新连接测试

不要一上来就重装系统，也不要盲目重启服务器。

很多 SSH 连接失败的问题，最后都是端口、防火墙、安全组其中一个环节没放行。

十二、后续优化措施

为了避免以后再次出现类似问题，我做了几个调整：

• 记录服务器 SSH 端口

• 修改端口前先放行防火墙

• 云平台安全组同步放行端口

• 保留 VNC 登录方式

• 不随意关闭 22 端口，确认新端口可用后再处理

• 定期检查防火墙规则

尤其是修改 SSH 端口时，一定要先放行新端口，再测试新端口能否连接，确认没问题后，再考虑关闭默认 22 端口。

否则很容易把自己挡在服务器外面。

写在最后

SSH 突然连接不上服务器，不一定是服务器宕机，也不一定是密码错误。

这次问题最终是 SSH 端口修改后，防火墙没有同步放行，导致外部无法连接。

遇到类似问题时，先判断服务器是否在线，再通过 VNC 检查服务、端口、防火墙和安全组，基本就能快速定位原因。

服务器运维最怕的不是故障本身，而是不知道该从哪里开始查。