先说个真实场景某天同事跑过来说我新装的 CentOS 7 用 SSH 连不上22 端口根本无法访问我过去一看客户端一直卡在连接超时ping 虚拟机倒是通的。这种问题我在工作中碰到太多次了从新手到老手从物理机到虚拟机22 端口不通的原因五花八门但绝大多数都逃不开网络连通性、防火墙策略、sshd 服务状态、SELinux 限制这四类。这篇文章就围绕 CentOS 7 的 22 端口无法访问把我的排查思路、操作命令和踩坑经验完整写出来适合刚装完 CentOS 7 却连不上 SSH 的新手也适合被远程服务器折腾到没脾气的运维同行参考。1. 先搞清楚是连不上 22还是压根找不到机器很多人在排查 22 端口问题时第一步就冲进服务器里去改防火墙、重启 sshd结果折腾半天发现是 IP 都没配对。所以别急着动手先通过客户端的报错信息判断故障到底出在哪个层级这能帮你省下大量时间。1.1 从报错信息反推问题层级我用 Windows 自带终端或 MobaXterm 连接 CentOS 7 时最常见的报错就两种一种是Connection timed out另一种是Connection refused。这两个提示看着差不多对应的故障点完全不同。Connection timed out连接超时说明客户端发出的 SYN 包发出去之后石沉大海要么是目标 IP 压根不可达要么是中间有防火墙把包悄悄丢弃了。这种情况我通常直接怀疑网络层问题比如虚拟机网卡没起来、IP 配错网段、路由不通或者是云平台安全组把入站流量拦截了。而Connection refused连接被拒绝说明服务器网络是通的数据包能正常到达但目标端口上没有进程在监听操作系统直接回了 RST 包。这时候重点就要放到 sshd 服务本身服务有没有启动、监听端口是不是改成了别的、sshd_config 有没有语法错误。有个小技巧我一直在用在客户端机器上执行telnet 目标IP 22如果端口通了会看到 SSH 版本号字符串如果不通则会出现Unable to connect to remote host之类的提示。Windows 10 之后的系统自带的 telnet 客户端默认没启用你可以去启用或关闭 Windows 功能里勾上或者干脆用 PowerShell 里的Test-NetConnection IP -Port 22一步到位。1.2 用 ping 和 traceroute 快速划分故障域拿到报错类型之后我再做一次快速的链路自测。习惯顺序是先ping 目标IP如果 ping 不通问题多半在网络层——本地网卡、网关、对端网卡这几处重点查如果 ping 通了但还是连不上 22 端口那就是端口层面的问题。ping 通只能证明 ICMP 协议能到达并不代表 22 端口能访问。有些网管会故意禁 ping有些防火墙会拦 ICMP 但放行 TCP反过来也一样所以 ping 不通不代表不能用 SSHping 通了也不代表 SSH 一定通。为了把问题切得更细我会再跑一下traceroute 目标IPCentOS 7 上是tracerouteWindows 上是tracert。看路由路径上哪一跳断了基本就能把故障域缩小到本地出口、中间运营商链路或目标主机本地这三部分之一。如果你是 VMware 虚拟机里装的 CentOS 7这一步尤其重要——物理机 ping 虚拟机不通的时候90% 是虚拟网络模式的问题这个我在后面单独章节展开。2. firewalldCentOS 7 上最容易被冤枉也最常出问题的端口管控层如果网络层没问题那接下来 90% 的概率会撞上 firewalld。CentOS 7 默认不带 iptables 服务而是用 firewalld 做防火墙管理这对习惯了 CentOS 6 的老运维来说第一反应就是去执行service iptables stop结果发现系统提示找不到服务然后一脸懵。2.1 为什么 CentOS 7 默认开 firewalld 而不是 iptablesCentOS 7 把防火墙从静态规则集改成了动态管理后台。firewalld 本身不直接操作内核网络栈而是通过 D-Bus 接口把规则下发给底层的 iptables 或 nftables但它多了一个叫区域zone的概念——你可以把不同网卡划分到不同信任等级的区域里比如内网网卡放 public 区、外网网卡放 external 区。这样做的好处是规则可以热更新不用像以前一样改一条规则就要 restart 一遍 iptables。这个设计本身挺好但对刚从 CentOS 6 迁移过来的人来说完全是新思路。你直接在命令行执行iptables -L是能看到默认链的但那些规则并不完全是 firewalld 全量同步的结果很多人在这里被绕晕。我的建议是只要你的 CentOS 7 上 firewalld 服务是 active 状态就以 firewalld 的命令为准别混用。2.2 停掉防火墙的三种方式和它们的副作用网上搜关掉 centos7 的防火墙命令搜出来的无非这三种systemctl stop firewalld只是临时停止机器重启后 firewalld 会重新启动规则原样加载回来。如果你只是想当下测试是不是防火墙挡的 22 端口这个命令够用。systemctl disable firewalld是把开机自启关掉但服务在当前这次运行里如果还活着你依然要先 stop 才能让规则立刻失效。这个操作风险比较大因为服务器重启后防火墙不再自启等于裸奔在网络上。systemctl mask firewalld是更彻底的禁用它会把 firewalld 服务符号链接到 /dev/null任何依赖它的操作都无法把它拉起来。一般只有明确知道自己要长期关闭防火墙时才建议这么做。我个人的态度是能不放行就尽量别关闭。防火墙不是故意跟你作对它的存在就是为了挡住那些无差别扫描你 22 端口的脚本。你要是图省事把防火墙一关了之过两天服务器被爆破、被植入挖矿程序哭都来不及。真正合理的做法是放行指定端口。2.3 正确的做法放行 22 端口而不是关防火墙在 CentOS 7 上给防火墙放行 22 端口我这几年用下来最稳的一套命令是这样的firewall-cmd --permanent --add-servicessh firewall-cmd --permanent --add-port22/tcp firewall-cmd --reload firewall-cmd --list-all--add-servicessh其实是把系统预定义的 ssh 服务规则加进去底层展开就是 22/tcp--add-port22/tcp是直接按端口放行。两者选一个就行都写上也没有冲突。关键是--permanent参数它表示写入永久配置如果不加这个参数规则只在当前运行时生效一旦 reload 或重启就没了。--reload的作用是让永久配置生效这个动作在连接 MySQL、Nginx 之类的场景下不会中断已有连接非常安全。--list-all是查看当前区域开放了哪些端口和服务出去运维排障第一件事我就用它看。如果你前面误操作关掉了防火墙也别急着重新开启先用--list-all确认当前哪些端口是放行的免得开起来之后反而把自己 SSH 堵死了。提示如果你修改了 sshd 的监听端口比如改成 2222那这里--add-port写的就是2222/tcp再顺手执行一下semanage port -a -t ssh_port_t -p tcp 2222否则即使防火墙放行了SELinux 照样拦你。这个坑后面专门讲。3. sshd 配置和 SELinux端口通了却依旧连不上的隐藏原因防火墙放行之后22 端口还是连不上这时候就要怀疑 sshd 服务本身和 CentOS 7 特有的 SELinux 限制。这块隐蔽性很高我曾经在一台服务器上排查了一下午最后发现是 SELinux 把非标准 SSH 端口给拦了防火墙反而全程无辜。3.1 sshd_config 中容易被忽略的三个参数SSH 服务端的核心配置文件是/etc/ssh/sshd_config。默认情况下 22 端口是监听在所有网卡上的但如果你之前做过配置下面三个地方最容易被忽视Port 22这一行决定了监听端口。有些人在配置多实例 SSH 时加了两行Port第一行被注释了但第二行的端口又改了结果外面一直在连 22服务却在别的端口上。排查时用ss -tlnp | grep ssh看本地实际监听端口比看配置文件更直观。ListenAddress 192.168.1.10如果被启用sshd 就只监听你指定的那一个 IP而不是默认的 0.0.0.0。如果你记不清服务器上到底配置了几个 IP很可能在外面连的那个 IP 根本没人在监听。PermitRootLogin no不影响端口是否能访问但它会在密码认证阶段直接把 root 拒掉表现为端口通、密码对、就是进不去。如果你是用 root 账号连接而配置里写的是prohibit-password那就只能走密钥登录。判断 sshd 有没有真的跑起来我建议看三条命令的结果systemctl status sshd看服务状态ss -tlnp | grep :22看端口监听情况sshd -t检查配置语法。第三条很多人会忽略但它在 sshd 重启前就能把配置文件的语法错误暴露出来避免你手一抖改错配置重启失败把自己锁在服务器外面。3.2 SELinux 对端口的强制约束semodule 和 sesearchCentOS 7 默认开了 SELinux在 enforcing 模式下不光文件有安全上下文标签端口也有类型标签。sshd 这个进程被 SELinux 限制为只能绑定带有ssh_port_t标签的端口。你用semanage port -l | grep ssh能查到这个类型的默认端口列表。如果你把 SSH 端口改成 2222防火墙放行了 2222sshd 也监听 2222 了但 SELinux 仍然会拒绝进程绑定这个未经授权的端口。表现非常迷惑人systemctl start sshd看状态是 active但ss -tlnp就是看不到 2222 在监听或者日志里写着Permission denied。正确的处理方式是给 SELinux 增加端口类型映射semanage port -a -t ssh_port_t -p tcp 2222semanage 命令属于 policycoreutils-python 包如果你执行的时候提示command not found先安装yum install -y policycoreutils-python实在排查不出来的时候我偶尔会用setenforce 0临时把 SELinux 切成 permissive 模式来验证问题。如果一关就通基本可以确定是 SELinux 拦截验证完后马上setenforce 1恢复。这不是让你长期关闭 SELinux只是排查手段记住生产环境里关了 SELinux 等于少了一层纵深防御要靠它挡的东西太多了。4. VMware 虚拟机和 NAT 网络里的 22 端口玄学这几年我遇到的centos7 22端口无法访问有相当大一部分发生在 VMware Workstation 虚拟机里。宿主机能和虚拟机互相 ping 通但 SSH 就是时通时不通或者干脆不通。这里面的坑比其他裸金属场景多得多。4.1 网卡模式选错了虚拟机有 IP 你也访问不到VMware 虚拟机默认有桥接、NAT、仅主机三种网络模式很多人创建虚拟机时一直点下一步最后用的是 NAT 模式。NAT 模式下虚拟机通过宿主机上网从虚拟机角度看它的流量是先到宿主机虚拟网卡再被宿主机转发出去。这个时候你可以从宿主机 ping 通虚拟机但如果你想像运维远程服务器那样在办公室一台电脑上通过局域网地址直连这台虚拟机的 22 端口NAT 模式默认不会把入站流量转发给虚拟机。排查顺序我建议这样来先在虚拟机里执行ip addr或ifconfig -a确认当前 IP 是什么。注意 CentOS 7 最小化安装默认是没有 ifconfig 命令的需要yum install -y net-tools否则你连 IP 都查不到。然后回到宿主机先ping 虚拟机IP通了再telnet 虚拟机IP 22。如果 ping 不通大概率是网卡模式或虚拟网络编辑器配置出了问题如果 ping 通但 telnet 不通那就是防火墙或 sshd 的问题。如果你是在家里搭了个 VMware 测试环境、虚拟机装完 CentOS 7 后死活 SSH 不上最省事的一招是打开编辑 - 虚拟网络编辑器看看当前 NAT 模式对应的网段比如是 192.168.137.0然后把你虚拟机 IP 改成同一网段宿主机侧也确认 VMware NAT 网卡的 IP 没被别的程序占用。这样从物理机访问虚拟机 22 端口就顺畅多了。4.2 ifconfig 查不到 IP问题往往出在 NetworkManager 和网卡配置还有一个高频现象虚拟机装完 CentOS 7进去敲ifconfig结果只有 lo没有 eth0 或 ens33 的地址。很多人第一反应是网卡坏了其实大多数情况是网卡默认没启用。CentOS 7 的网卡配置在/etc/sysconfig/network-scripts/ifcfg-ens33核心参数是ONBOOT。默认镜像如果没装好后改过ONBOOT 可能是 no意味着开机时系统不会自动拉起这块网卡。改成 yes 再重启网络即可vi /etc/sysconfig/network-scripts/ifcfg-ens33 # 把 ONBOOTno 改成 ONBOOTyes systemctl restart network这里还要注意 NetworkManager 的参与。CentOS 7 上网络最终是由 NetworkManager 管理的你光改配置文件忘了重启 network 服务或者 NetworkManager 缓存了旧配置都可能造成 IP 不生效。我习惯改完配置后执行systemctl restart NetworkManager然后再ip addr show确认。虚拟机克隆引起的网卡问题也很经典。你用模板克隆出来的新虚拟机ifcfg 文件里还留着旧机器的 MAC 地址和 UUID结果网卡起不来。处理办法是把/etc/sysconfig/network-scripts/ifcfg-ens33里的 UUID 删掉HWADDR 改成新网卡的 MAC然后重启 network。不然你 22 端口再怎么排查都白搭——机器根本没有地址可以让你连。5. 从 22 端口打不开延伸到连外网都不通的连锁故障有时候 22 端口连不上只是一个更复杂网络故障的冰山一角。比如你 ping 得通网关但 ping 不通外网或者能 ping 通 IP 但解析不了域名。这类问题不解决就算你把 SSH 服务端调得再好客户端照样连不上。5.1 DNS 配置导致的假性无法访问很多人在 CentOS 7 里执行ping www.baidu.com报unknown host然后以为整台机器网络断了。这其实只是 DNS 的问题。CentOS 7 的 DNS 配置文件是/etc/resolv.conf如果你安装时没配好或者 DHCP 下发的 DNS 在系统重启后被覆盖里面可能为空或者指向了一个不可达的地址。手工写一个可用的 DNS 配置vi /etc/resolv.conf nameserver 223.5.5.5 nameserver 114.114.114.114如果你是用 SSH 客户端以域名连接 CentOS 的那这个 DNS 问题会直接让你连不上 22 端口因为域名解析那一步就失败了。所以碰到无法访问的报错先看一眼是不是能 ping 通 IP能 ping 通 IP 不能 ping 通域名八成是 DNS。5.2 网关与路由表问题导致有去无回TCP 三次握手是双向的你发送的 SYN 包到了服务器服务器回的 SYN-ACK 也需要沿着正确的路由回到你这边。如果 CentOS 7 的默认网关配置错了它收到了请求也回复不了客户端看到的依然是超时。我在现场排查 22 端口不通时跑的最多的就是下面这两个命令ip route route -n看输出里有没有default via这一行。没有默认路由机器出了本机网段就不知道怎么走SSH 的连接建立自然失败。如果你发现网关地址写错了去 ifcfg 文件里把GATEWAY改对然后重启 network。有种情况特别迷惑人虚拟机从 DHCP 拿到的网关是 192.168.137.1但 VMware 虚拟网络编辑器的 NAT 网关改成了 192.168.137.2结果虚拟机还是拿旧网关去上网导致回包路径断裂。这种问题重启 network 或重新 DHCP 一次就能解决但排查时想不到这一点会折腾很久。5.3 顺手把 yum 源换成国内源实测网络问题的连带修复网络层面一出现问题很多人第一反应是用 yum 装东西试试结果卡在下载不动于是更加确信网络断了。CentOS 7 官方源一直在维护但国内访问速度确实不稳定。我曾经在一台低配测试机上停掉防火墙、放行端口、重启 sshd什么都做了22 端口还是超时后来发现其实是宿主机上行带宽被占满流量出不去。检查这类问题时我习惯在 CentOS 7 上执行curl -I http://mirrors.aliyun.com如果返回 HTTP 头说明出口网络至少能访问到外部 IP。为了后续安装依赖不磨叽顺手把 yum 源换成阿里云的国内镜像mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache这一步对修 22 端口本身没有直接作用但它能帮你确认这台机器到底能不能正常访问外网同时为接下来安装 net-tools、policycoreutils-python 这些排障工具做好准备。很多时候你连不上 22 端口只是因为你少装了排查工具没法把问题定位清楚越查越乱。6. 我排 22 端口故障时的实战清单以及几个容易自己坑自己的细节上面几章基本把原因讲完了但真实排障过程中很多人并不是不知道这些知识点而是不知道按什么顺序查。我把自己的排查顺序整理成一个清单你可以直接照着执行。它不能保证 100% 解决问题但能保证你不再东一榔头西一棒子。第一步客户端执行 ping 目标IP确认网络层通不通 第二步客户端执行 telnet 目标IP 22判断端口是否可达 第三步服务器上执行 systemctl status sshd确认服务活着 第四步服务器上执行 ss -tlnp | grep 22确认监听地址和端口 第五步服务器上执行 firewall-cmd --list-all确认防火墙放行情况 第六步服务器上执行 getenforce确认 SELinux 状态 第七步服务器上执行 ip route确认默认网关这套流程走完90% 的 22 端口无法访问问题都能找到根因。剩下的 10% 基本都是比较个别的配置错误比如 sshd_config 里写了奇怪的 AllowUsers、云平台安全组规则没放行、宿主机虚拟网卡被禁用等等。下面这张表是我根据实际踩坑经验整理的症状对应到根因和解决办法贴在旁边随时能翻。症状常见根因优先排查位置telnet 22 超时防火墙拦截或网络不可达firewalld 规则、路由表、VMware 模式telnet 22 拒绝sshd 未启动或端口不符sshd 状态、ss -tlnp、sshd_configping 通但 SSH 极慢UseDNS 开启导致反向解析sshd_config 里设置 UseDNS no端口已放行仍连不上SELinux 端口类型未配置semanage port -lifconfig 无 IPONBOOTno 或未装 net-toolsifcfg-ens33、NetworkManager宿主机能连虚拟机局域网连不上NAT 模式没有端口转发虚拟网络编辑器、桥接模式最后再说三个我真实踩过的坑每一个都是血泪教训。第一个坑是我曾经帮客户运维一台 CentOS 7远程连接突然断了我怎么都连不上 22 端口最后跑到机房一看是上一个人为了安全把 sshd_config 里 Port 改成了 2222但忘了把防火墙和 SELinux 里面的映射一起改掉。改配置之前永远先备份一份cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak改完之后先sshd -t验证语法再systemctl restart sshd。绝对不要在没有 backup 的情况下重启 sshd否则你连改回来的机会都没有。第二个坑是关于关闭防火墙的。有一次我在 VMware 里搭测试环境图省事执行了systemctl stop firewalld然后发现重启虚拟机之后防火墙又回来了因为我没有执行 disable。后来我就不再习惯性关防火墙了而是养成把需要用的端口逐个放行的习惯。这个习惯看起来多敲几条命令但能避免生产环境里关防火墙一时爽被扫描火葬场的尴尬局面。第三个坑是关于 MobaXterm 这类终端工具的。你在客户端工具里保存的 SSH 会话如果之前绑定的是旧 IP虚拟机重新 DHCP 拿到新地址之后你双击会话还是连旧 IP自然 22 端口无法访问。这种问题跟服务器配置毫无关系却浪费了我不少时间。遇到连不上的时候先在工具的会话配置里确认目标 IP 是不是服务器当前的真实 IP别一上来就怀疑服务器。SSH 22 端口问题排查整体上就是一个由外到内、由链路到服务的过程。不看报错凭空猜是最浪费时间的我这几年养成的习惯是先看客户端报错是超时还是拒绝然后 ping 一下确认目标活着按照那七步清单一路查下去绝大多数问题在十分钟内能定位。希望这篇东西能帮你省下那些我曾经浪费过的排查时间。