ssh连不上虚拟机，绝大多数卡在网卡、端口和防火墙三处
遇到ssh连不上虚拟机,不要先怀疑系统坏了，按“网络通不通 → 端口通不通 → 服务起没起 → 防火墙拦没拦”的顺序排查，多数问题五分钟内能定位，下面直接按这个顺序拆解。
判断ssh连不上虚拟机是网络问题还是服务问题
先分清现象,不同报错指向完全不同的故障点，打开终端执行 ssh user@虚拟机IP，看报错：
- Connection timed out（超时）：数据包根本没到达虚拟机，问题出在网络链路或防火墙丢弃
- Connection refused（拒绝连接）：数据包到了，但22端口没监听或被防火墙拒绝
- Permission denied（认证失败）：网络和端口都正常，问题在密码、密钥或sshd配置
超时和拒绝是两类不同的问题，前者先查网卡和路由，后者直接检查ssh服务和防火墙规则，很多人一上来就重启sshd，结果浪费大量时间。
用ping测试虚拟机网络连通性
从宿主机执行 ping 虚拟机IP：
- ping通：说明二层网络没问题，转向查端口和服务
- ping不通：检查虚拟机IP地址是否配错，网卡是否处于启用状态
注意,某些云环境或开启了禁ping策略的虚拟机，即使网络正常也不回显ICMP包，如果ping不通，不要直接断定网络有问题，改用其他方式验证。
ssh连接虚拟机超时，先从网卡和IP配置下手
虚拟机的网卡模式选错了，怎么配都白搭
用VMware或VirtualBox创建虚拟机时,网卡模式直接影响ssh可达性，用表格对比几种常见模式：
| 网卡模式 | 宿主机能否访问 | 局域网其他机器能否访问 | 典型用途 |
|---|---|---|---|
| NAT | 能 | 不能 | 虚拟机上网为主 |
| 桥接 | 能 | 能 | 虚拟机需要局域网互通 |
| 仅主机 | 能 | 不能 | 隔离调试环境 |
如果用NAT模式连不上，先看虚拟网卡是否被禁用，Windows下打开“网络适配器选项”，找到VMware Network Adapter VMnet8或VirtualBox Host-Only Network，右键启用，这个步骤很多人忽略，尤其是重装系统或更新驱动之后。
ip addr查看IP是否在同一网段
登录虚拟机控制台（VMware界面或VNC），执行：
ip addr看eth0（或ens33等）是否有IP地址，如果网卡没获取到IP，执行 dhclient 或 systemctl restart network 重新获取。虚拟机和宿主机必须能互相路由，这是ssh连通的最低要求。
检查默认网关：
ip route如果默认网关缺失,虚拟机只能访问宿主机，访问局域网其他机器会失败，ssh同理。
宿主机防火墙拦了虚拟网卡流量
Windows宿主机自带的防火墙有时会拦截VMware或VirtualBox的虚拟网卡流量,排查方法：
- 打开“Windows Defender防火墙” → “允许应用通过防火墙”
- 找到VMware或VirtualBox相关进程,确认专用和公用都有勾选
- 如果找不到对应条目,手动添加入站规则，放行虚拟机网卡所在网段
Linux宿主机检查 iptables -L -n 和 firewall-cmd --list-all，确认没有DROP规则。
检查ssh端口是否打开：一条命令分清故障段
用nc或telnet测试22端口连通性
在宿主机上执行：
nc -vz 虚拟机IP 22或者：
telnet 虚拟机IP 22端口开着：输出显示Connected（连接成功），直接跳到ssh服务本身去排查。连接超时：防火墙DROP了包，查iptables和firewalld。立即拒绝：sshd没监听或端口配置不是22。
sshd服务状态和监听地址确认
登录虚拟机控制台,执行：
systemctl status sshd确认服务是active（running）状态，然后检查监听地址：
ss -tlnp | grep 22如果监听地址是0.0.0.0或::，说明sshd在所有网卡上监听，问题不在服务端。如果监听地址是127.0.0.1，说明sshd只允许本机连接，修改配置文件后重启服务即可。
修改sshd监听地址的方法：
vi /etc/ssh/sshd_config找到 ListenAddress 行，改成 0.0.0，保存后执行 systemctl restart sshd。
firewall-cmd和iptables规则逐一核对
CentOS/RHEL/Fedora系用firewalld：
firewall-cmd --list-all确认 services: ssh 或 ports: 22/tcp 是否有输出，没有就执行：
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reloadUbuntu/Debian系用ufw：
ufw status输出为active的话,执行
ufw allow 22/tcp 放行。
老系统用的iptables：
iptables -L -n --line-numbers看INPUT链是否有DROP或REJECT策略优先于放行规则。规则顺序很重要，DROP放在放行规则前面会直接丢弃流量。
云平台安全组是虚拟防火墙的最后一关
如果用的是云虚拟机（简米云、酷番云、AWS等），宿主机防火墙之外还有安全组隔离层，登录云控制台，找到安全组规则，确认入方向放行了TCP 22端口。安全组规则修改后通常立即生效，不用重启实例。
常见坑是：自己用iptables放行了22端口，但安全组没放行，结果ssh还是连不上，反过来，安全组放行了22端口，但虚拟机内部firewalld拦了，同样连不上。两层都要检查。
虚拟机的防火墙规则改了，ssh反而连不上了
排查思路从“网络”转到“服务”
如果之前ssh能正常连,改完防火墙规则后突然连不上，大概率是防火墙策略调整时误删了放行规则，或者添加了错误规则，逐个排查：
- firewalld：
firewall-cmd --list-all查看当前放行列表，确认ssh服务还在 - iptables：
iptables -L INPUT -n --line-numbers查看每条规则顺序 - ufw：
ufw status verbose看入站策略是allow还是deny
确认sshd没有更改端口编号
改过sshd_config里 Port 配置后发现ssh连不上，先确认改动是否正确：
grep -E "^Port" /etc/ssh/sshd_config如果显示端口为2200,执行ssh时要用 ssh -p 2200 user@IP。还要确认防火墙已经放行新端口，firewalld只放行了22的话，改完sshd端口后必然连不上。
改回方法：把Port改回22，systemctl restart sshd。
SELinux导致ssh端口异常
CentOS开启SELinux的话,即使防火墙放行了新端口，SELinux也会拦截，查看SELinux状态：
getenforce输出Enforcing的话,执行:
semanage port -a -t ssh_port_t -p tcp 新端口号让SELinux放行自定义端口,也可以临时关闭SELinux测试（setenforce 0），但生产环境不建议长期关闭。
密钥登录场景下ssh连不上虚拟机的排查重点
authorized_keys权限不对，密钥校验直接失败
用密钥登录时,ssh对文件权限要求严格。任何目录权限过宽都会导致登录被拒绝，逐一检查：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa（私钥）
另外确认sshd_config里 PubkeyAuthentication yes 没有注释掉。
密码登录和密钥登录互斥时怎么处理
有时为了安全把 PasswordAuthentication 设成no，但密钥又缺失或损坏，结果ssh连不上虚拟机，恢复方法：
- 通过云控制台的VNC/管理终端登录虚拟机
- 改回
PasswordAuthentication yes - 重启sshd后再用密码登录检查密钥问题
这类问题在线上运维中很常见,建议修改配置前先备份原始文件。
局域网常见场景：vmware虚拟机ssh网络配置怎么改才能通
反应最多的是VMware里创建的Linux虚拟机,用NAT模式能上网，但宿主机ssh连不上，按这个顺序操作：
- 看虚拟网络编辑器：在VMware菜单栏选“编辑”→“虚拟网络编辑器”，确认VMnet8的网段，比如192.168.88.0
- 看虚拟机IP：登录虚拟机执行
ip addr，确认IP属于VMnet8网段，比如192.168.88.128 - 看宿主机VMnet8适配器IP：Windows下执行
ipconfig，确认宿主机的VMnet8地址也是192.168.88.1，三者同网段才能互通
如果改了虚拟网络编辑器网段，宿主机VMnet8的IP地址要同步修改，否则网络不通，这个同步动作经常被忽略，修改完重启VMware DHCP服务后才能生效。
常见问题排查
为什么ssh连接虚拟机总是显示Connection timed out
Connection timed out说明数据包发出去了但没有响应，优先检查虚拟机IP是否变化（DHCP重新分配了地址）、宿主机到虚拟机之间是否有路由、虚拟网卡是否被宿主机防火墙拦截，逐项排除后，多数情况能定位到具体环节。
虚拟机防火墙关闭后ssh还是连不上怎么查
关闭防火墙后仍连不上,问题基本不在iptables或firewalld层面，检查sshd服务是否正常运行、监听地址是否正确、SELinux是否拦截，同时确认网卡BRIDGE或NAT模式是否和IP地址匹配，桥接模式下虚拟机IP如果和其他机器冲突，也会导致ssh连接异常。
VMware虚拟机用NAT模式ssh不通，桥接反而能通是怎么回事
这类情况多半是VMnet8网段和宿主机虚拟网卡配置不一致,或者VMware NAT服务异常，可以在Windows服务管理器里重启VMware NAT Service和DHCP Service，再检查VMnet8的IP和虚拟机IP是否同网段，桥接模式走物理网卡，绕过了虚拟NAT层，所以连通性更直接。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/631362.html
