昨天帮一个朋友排查服务器问题，折腾了快两个小时，最后发现是安全组里只开了22端口，但忘了放行ICMP。这让我想起很多刚接触云服务器的朋友，经常遇到SSH连接超时的问题，上来就怀疑是密码错了、服务挂了，其实绝大多数情况都是安全组规则没配明白。

先确认SSH服务本身是不是活着

在动安全组之前，先看一眼服务器上的SSH服务状态。如果你还能通过云厂商的VNC或者管理终端进去，执行：

systemctl status sshd

正常会显示active (running)。如果服务是挂的，那跟安全组没关系，先systemctl start sshd把服务拉起来再说。

另外确认一下端口号，默认是22，但有些人为了安全会改成别的端口。用netstat -tlnp | grep sshd看一眼实际监听的端口，记下来，后面配规则要用这个数字。

安全组到底是个什么东西

简单说，安全组就是云服务器外围的一道防火墙。你服务器里面即使把防火墙关了，安全组依然会拦截流量。很多新手容易忽略这一点——在本地ping不通服务器，第一反应是禁ping了，其实很可能安全组根本没放行ICMP协议。

安全组是白名单机制，只放行你明确允许的规则，其余全部拒绝。所以“超时”这个现象，本质上就是你的SSH请求包发过去了，但安全组没让进，客户端等到超时就报错了。

常见的安全组配置错误

只开了22端口但没开ICMP

很多人配置安全组的时候，入方向只加了一条：允许22端口的TCP协议。但实际网络排查时，ICMP协议用于ping和traceroute，如果不放行，你连服务器通不通都测不了。推荐的做法是入方向至少放行ICMP，方便日常调试。

只加了22端口，但SSH改了端口

有些人为了防暴力破解，把SSH端口改成了比如2222。安全组里还只放行22，那肯定连不上。修改了SSH端口之后，记得同步更新安全组的入方向规则。

授权对象写错

常见写法是0.0.0.0/0表示允许所有IP访问。如果你写成了127.0.0.1/32或者某个不正确的网段，那只有那个IP能连。特别是有些云厂商的控制台默认会填你当前浏览器的公网IP，如果你用了代理或者公司网络出口经常变，这个IP可能早就变了。

规则优先级搞混了

大部分云厂商的安全组规则是按顺序匹配的，一旦匹配到就停止往下走。如果你在拒绝规则后面加了允许规则，那允许规则根本不会生效。建议把常用的允许规则放在前面，拒绝规则放最后。

逐层排查的思路

遇到SSH超时，按这个顺序查，别上来就改配置：

1. 先在本地ping一下服务器IP。通的话，说明网络层没问题，问题在传输层以上。不通的话，检查安全组是否放行ICMP，或者服务器是否禁用了ping。

2. 用telnet测试端口通不通。telnet 你的服务器IP 22，如果一直卡在Connecting...然后超时，基本就是安全组没放行。如果能连上，会显示SSH的版本信息。

3. 检查服务器内部防火墙。CentOS 7以上用firewall-cmd --list-all，Ubuntu用ufw status。有时候你改完安全组，但服务器内部的防火墙还拦着。

4. 去云厂商控制台看安全组规则。逐条核对入方向规则，确认有放行SSH端口的规则，且授权对象包含了你的IP或者0.0.0.0/0。

正确的安全组配置示例

入方向至少包含这几条：

如果你有固定的管理IP，建议把0.0.0.0/0换成你的具体IP，更安全。没有固定IP的话，就只能用0.0.0.0/0。

还有一个容易忽略的点

有些云厂商有两层安全组，一个是实例级别的安全组，一个是VPC层面的网络ACL。网络ACL是子网级别的防火墙，如果ACL里没放行，安全组放行也没用。一般默认ACL是全放行的，但如果你手动改过，记得检查一下。

另外，改完安全组规则之后不需要重启服务器，也不用重启SSH服务，规则是实时生效的。如果改完还连不上，等个一两分钟再试，有些厂商的控制台有缓存延迟。

实在不行就开控制台终端

云厂商一般都会提供网页版的VNC或者管理终端，这个是不经过安全组的，直接连到服务器。通过这个方式进去，先用ss -tlnp | grep sshd确认服务监听的端口和地址，然后curl -v telnet://127.0.0.1:22测一下本地能不能通，本地能通的话，问题绝对在外围。

最后说一句，很多人喜欢把SSH超时和“被墙”联系起来，对于国内的云服务器来说，先检查安全组，99%的问题都出在这里。

如果你按照上面的步骤查完还是不行，多半是云厂商控制台的操作界面有些特殊的开关——比如“是否启用安全组”这个复选框没勾上，或者绑定了多个安全组之间有冲突，逐个禁用排查就好。

希望这篇文章能帮你少走点弯路。下次再遇到SSH超时，别急着重启服务器，先去安全组里看一眼。