MobaXterm无法连接CentOS虚拟机？从SSH到防火墙的排查指南

MobaXterm连不上自己虚拟机里的CentOS，这大概是VMware新手踩过最密集的坑之一。系统装好了，登录界面也能进，但打开MobaXterm准备远程操作时，不是弹红叉就是一直转圈，什么“Connection refused”“Network is unreachable”看得人头皮发麻。我前后帮不少同事排查过这类问题，自己也反复被这些莫名其妙的现象折腾过，所以今天干脆把“MobaXterm无法连接虚拟机CentOS”这个场景完整拆一遍，从网络通不通、SSH服务有没有启动，再到MobaXterm这边的会话配置，每一步都讲清楚。

这篇文章适合谁看？刚装好CentOS想用MobaXterm练手的新手，以及被连不上问题折腾了半天、又找不到系统排查思路的开发者和运维朋友。看完之后你会发现，连不上这件事，大部分原因不在MobaXterm本身，而是虚拟机网络、SSH服务、防火墙这几个“上游环节”出了问题。

1. 先搞明白：MobaXterm连不上CentOS，问题到底出在哪一层

1.1 一次SSH连接要经过的完整链路

MobaXterm连接虚拟机里的CentOS，本质上就是一次SSH远程登录。SSH是Linux系统默认自带的远程管理协议，默认走22端口。MobaXterm作为客户端，向CentOS的22端口发起加密连接请求，CentOS里的sshd服务收到请求后验证用户名和密码，验证通过，就建立起一个远程shell会话。

这条链路看着简单，但中间任何一环断了，最终表现都是“连不上”。我把这条链路拆成四段：

• 第一段：虚拟机和宿主机（Windows）之间的网络是通的，虚拟机有IP，宿主机能访问到这个IP。
• 第二段：CentOS系统里的sshd服务进程在运行，并且监听在22端口上。
• 第三段：CentOS的防火墙和SELinux没有把22端口或SSH流量拦下来。
• 第四段：MobaXterm这边填写的IP地址、端口号、用户名、密码全部正确。

有一个通俗的类比：MobaXterm就是快递员，虚拟机IP是收件地址，sshd是家里愿意开门接快递的人，22端口是大门，防火墙和SELinux是小区保安，用户名密码是收件人身份信息。快递员找不到地址，家里没人，大门锁死，保安不让进，任何一个环节出问题，包裹都送不到。

所以排查“连不上”问题，正确思路就是按这条链路从前往后查，而不是一开始就盯着MobaXterm的配置乱改。我见过太多人在MobaXterm里翻来覆去改设置，最后发现虚拟机压根没有IP，完全是白费力气。

1.2 不同错误提示对应的排查方向

MobaXterm连接失败时，窗口里会显示不同的错误信息，这些信息其实就是诊断线索。不同提示代表故障发生的位置完全不同，看一眼大概能定位到排查方向。

刚开始排查的时候，先看MobaXterm给出的提示属于哪一类，再决定往哪个方向查。如果提示是“Connection timed out”，你在MobaXterm里改一百遍端口都没用，因为问题出在网络层或者防火墙。如果提示是“Permission denied”，那网络和SSH服务大概率是通的，问题出在账号密码。

我就是靠这套“提示定位法”一步一步缩小范围的。下面按照排查顺序，从网络层开始逐层往下讲。

2. 第一步排查：网络通不通，决定了后面所有操作

2.1 VMware网卡模式选错是头号原因

在排查看不到虚拟机IP之前，先确认VMware里虚拟机的网卡模式。VMware提供了三种虚拟网络模式，分别是NAT、桥接（Bridge）和仅主机（Host-Only）。

NAT模式是默认也是最省心的模式，对应VMnet8虚拟网卡。虚拟机的网络流量通过宿主机转发出去，对外表现为宿主机在上网，虚拟机在“借用”宿主机的网络。同时宿主机能访问虚拟机，虚拟机也能访问宿主机。这个模式最大的优点就是不用关心局域网环境，宿主机能联网，虚拟机就能联网。

桥接模式对应VMnet0，相当于把虚拟机直接接到宿主机所在的局域网里，虚拟机就像局域网里的一台独立机器。这个模式在配置正确的情况下功能最强，但非常依赖局域网的DHCP环境，一旦局域网里没有DHCP服务，或者有IP冲突，虚拟机就无法正常获取IP，连接自然也成问题。

仅主机模式对应VMnet1，虚拟机只能和宿主机通信，不能访问外网，一般用于特殊测试环境，日常使用很容易踩坑。

很多新手连不上的原因，就是把VMware的网卡模式设成了桥接，而桥接模式又在当前网络环境下获取不到IP。这时候MobaXterm自然是找不到目标的。排查看一下虚拟机设置里的网卡模式，如果不是NAT，建议先切成NAT试一下。

改网卡模式的方法：右键虚拟机 → 设置 → 网络适配器 → 选择“NAT模式”，然后重启虚拟机，让网卡重新获取配置。

2.2 在CentOS里确认IP地址是否正常

确认VMware网卡是NAT模式之后，进入CentOS系统，先看看虚拟机有没有拿到IP地址。在CentOS终端里执行：

bash复制ip addr

这条命令会列出所有网卡的状态。CentOS 7及以后版本，网卡名称一般是ens33或者ens160，找到有IPv4地址的那一块。正常情况下会看到一个类似192.168.x.x的地址，这就是虚拟机的IP，也是MobaXterm里要填的“Remote host”。

这里有个坑要说一下：CentOS的Minimal（最小化）安装默认不装net-tools工具包，所以早期的ifconfig命令很可能是“command not found”。这时候直接用ip addr就行，不用额外安装什么东西。

如果ip addr显示网卡有状态，但下面没有IPv4地址，说明网卡没有获取到IP。手动触发一下DHCP：

bash复制dhclient

或者用NetworkManager的配套命令：

bash复制nmcli connection up ens33

执行完再看一次ip addr，如果还是没有IP，就需要检查虚拟机网卡是否已经连接。VMware的虚拟机设置里有个“启动时连接”选项，如果没勾选，网卡虽然存在但状态是disconnected，这时候在虚拟机里执行：

bash复制nmcli device status

查看网卡是connected还是disconnected状态。如果是disconnected，用nmcli把网卡激活，然后再看IP。

看到IP之后，在Windows的命令行里ping一下这个IP：

code复制ping 192.168.x.x

能ping通，说明宿主机到虚拟机的网络链路是通的，可以进入SSH环节排查。ping不通，大概率是Windows这边的虚拟网卡或者VMware服务有问题，继续往下看。

2.3 Windows挔查vmnet8适配器状态

如果虚拟机里能看到IP，但Windows ping不通，问题往往出在Windows宿主机这一侧。Windows上用来支撑VMware虚拟网络的是两张虚拟网卡，NAT模式对应VMware Network Adapter VMnet8，仅主机模式对应VMware Network Adapter VMnet1。

打开Windows的网络连接窗口，可以按Win+R，输入ncpa.cpl回车。找到VMware Network Adapter VMnet8，确认它的状态是“已启用”。如果它被禁用了，右键启用即可。

还有一个更隐蔽的问题：VMnet8适配器在设备管理器里显示感叹号。这种情况通常是VMware虚拟网卡的驱动出了问题，可能是Windows更新后驱动不兼容，也可能是VMware升级后旧驱动残留。处理方式是在设备管理器里找到该网卡，右键卸载驱动，再重启电脑让系统自动重装；如果还不行，就用VMware安装包做一次修复安装。

另外，VMware虚拟网络编辑器里也能查看和修复网卡配置。在VMware菜单栏选择“编辑” → “虚拟网络编辑器”，点击右下角的“更改设置”（按钮显示的是管理员权限），查看VMnet8这一段是否正常。如果配置看起来混乱，直接点击“还原默认设置”，VMware会把所有虚拟网络重置为初始状态。这个方法能解决很多莫名奇妙的网络问题。

注意，还原默认设置会把手动改过的NAT网段、DHCP设置一并清掉，有自定义配置的话先截图备份。

3. 第二步排查：SSH服务、防火墙和SELinux

3.1 检查sshd是否在运行

网络通了，接下来看SSH服务本身是否正常工作。CentOS的SSH服务由openssh-server软件包提供，安装完成后服务名叫sshd。

在虚拟机里执行：

bash复制systemctl status sshd

如果输出里有“active (running)”字样，说明服务在运行，可以往下查防火墙。如果是“inactive (dead)”，说明服务没起来，先启动它：

bash复制systemctl start sshd

再把sshd设置为开机自启，免得虚拟机重启后还要手动拉起服务：

bash复制systemctl enable sshd

这里有个小细节值得说一下：很多教程都教你“安装完CentOS后SSH默认就是开启的”，但实际情况经常有例外。有的自定义安装流程会在安装阶段跳过openssh-server，也有的精简镜像默认只装了客户端，没有装服务端。所以systemctl status这一步不能跳过，必须亲眼确认服务状态。

3.2 没安装openssh-server怎么处理

如果是精简安装或者某些定制版镜像，执行systemctl start sshd时可能会提示“Unit not found”，这就说明系统里压根没装openssh-server。解决办法很简单，用yum装上：

bash复制yum install -y openssh-server

CentOS 7使用的旧版yum，CentOS 8及以后用dnf，但CentOS 8里yum命令通常也做了软链接，所以直接敲yum一般不会出错。安装完成后，再执行：

bash复制systemctl start sshd
systemctl enable sshd

然后确认一下sshd监听在哪个端口上：

bash复制netstat -tlnp | grep sshd

这个命令会显示sshd进程监听的地址和端口。正常情况下是0.0.0.0:22或者:::22，表示监听所有地址的22端口。如果这里显示的端口不是22，那MobaXterm里默认填的22端口肯定连不上，需要在MobaXterm里改成对应的端口号。

我遇到过有人为了“安全”，手动把sshd的监听端口改成了2222，结果自己和同事都忘了，排查了半天才发现是端口对不上。

3.3 防火墙和SELinux的“隐形阻拦”

网络通了、sshd也运行了，但MobaXterm还是报“Connection timed out”，这种情况十有八九是防火墙在作祟。CentOS 7默认开启了firewalld防火墙，CentOS 6则默认使用iptables。防火墙会拦截外部对22端口的访问，让连接请求“石沉大海”。

先查看防火墙状态：

bash复制systemctl status firewalld

如果状态是active，查看当前开放了哪些端口：

bash复制firewall-cmd --list-all

对于本地开发环境，最简单的测试方式就是把防火墙临时关掉：

bash复制systemctl stop firewalld

为了确认是不是防火墙的问题，关掉后再用MobaXterm连一次。能连上，就说明是防火墙拦截。这时候有两种选择：要么再把防火墙开启，放行22端口；要么干脆设置开机不启动防火墙。

放行22端口的方式：

bash复制firewall-cmd --zone=public --add-port=22/tcp --permanent
firewall-cmd --reload

执行完再确认一下：

bash复制firewall-cmd --list-ports

如果看到22/tcp，说明放行成功。生产环境推荐用放行端口而不是直接关闭防火墙，本地学习环境则随意，怎么省事怎么来。

除了防火墙，SELinux也是个不显山不露水的“隐形拦截者”。SELinux是全称Security-Enhanced Linux的内核级安全模块，CentOS默认开启。它在某些情况下会阻止sshd的正常访问，尤其是手动修改过端口或sshd配置的时候。查看SELinux状态：

bash复制getenforce

输出Enforcing表示强制开启，Permissive表示只记录不拦截，Disabled表示关闭。如果当前是Enforcing，想临时关闭测试：

bash复制setenforce 0

这句命令只对当前运行状态生效，重启后又恢复Enforcing。想永久关闭的话，要修改/etc/selinux/config文件，把SELINUX=enforcing改成SELINUX=disabled，然后重启。本地测试环境为了少踩坑，关掉SELinux是很多人的选择，但生产环境建议保留默认策略，毕竟安全机制不是摆设。

4. 第三步排查：MobaXterm会话配置与常见坑

4.1 新建SSH会话的填写要点

前两层排查完，接下来的重点就放回MobaXterm本身。很多连不上的问题，就是会话配置里一个不起眼的小细节填错了。

打开MobaXterm，点击顶部菜单的Session，在弹出的会话配置窗口里：

• 会话类型选择SSH，这个必须选对，选成Telnet或者RDP是绝对连不上的。
• Remote host一栏填写虚拟机的IP地址，就是前面用ip addr查到的那个192.168.x.x。
• Specifiy username勾选上，填写登录用户名，通常是root，也可以是普通用户。
• Port一栏保持22不变，除非你的sshd端口被改动过。
• 其他高级选项，比如SSH隧道、X11转发，第一次调试可以先不管，保持默认即可。

点击OK后，如果是第一次连接，MobaXterm会弹出一个确认SSH指纹的对话框，大致内容是询问你是否信任并保存这台主机的SSH密钥，选择Accept或Yes继续。然后输入密码，如果能正常进入终端界面，就大功告成了。

这里要说一个大坑：很多新手第一次连接时，看到密码输入框，以为光标不动就是没法输入，反复点。实际上SSH密码输入是隐式回显的，就是输入什么都不会显示，包括星号也不会显示。这是正常的安全机制，放心输入完按回车就好。

另外一个容易被忽略的点：如果Session的“Specify username”没有勾选，MobaXterm会在连接时要求你手动输入用户名，有些人以为默认就是root，结果输错用户名，提示Permission denied，白白折腾。

4.2 虚拟机IP变了，会话配置过期

还有一种很常见的“昨天还能连，今天突然连不上”的情况，原因是虚拟机的IP地址变了。

VMware的NAT模式默认启用DHCP，虚拟机的IP是动态分配的。如果虚拟机关机再开机，或者VMware的DHCP租约到期，虚拟机拿到的IP可能会变。而MobaXterm里保存的会话IP还是旧的，自然就连不上。

遇到这种情况，先到虚拟机里执行ip addr重新查一下IP，然后用新的IP去连。如果嫌麻烦，可以在CentOS里把IP固定下来。用nmtui命令打开NetworkManager的文本图形界面，选择“Edit a connection”，找到对应的网卡，把IPv4 configuration从Automatic改为Manual，然后填写一组本地环境用的静态IP。

静态IP的网段要跟VMnet8保持一致。在Windows命令行里运行ipconfig，看VMware Network Adapter VMnet8那一栏的IP地址，一般是192.168.x.1。那虚拟机里的静态IP就填同一网段，比如192.168.x.100，掩码255.255.255.0，网关填192.168.x.1，DNS可以填192.168.x.1或者114.114.114.114。

填完之后保存退出，重启网络服务：

bash复制systemctl restart network

再确认ip addr里IP已经变成静态IP，以后MobaXterm里就固定用这个IP，不会再出现IP变化导致连不上的问题。

4.3 SSH指纹冲突的典型解法

还有一种让人一头雾水的报错，MobaXterm的提示大概是“REMOTE HOST IDENTIFICATION HAS CHANGED”或者“Host key verification failed”。这句话的意思是：这台IP对应的SSH主机指纹和之前保存的不一样，大概率是这台虚拟机重装过系统，或者这个IP被别的主机占用过。

解决方式有两种。第一种最简单，删掉MobaXterm里这个报错的会话，重新新建一个会话，MobaXterm会重新确认并保存新的指纹。第二种是在命令行里清理本地保存的旧指纹，用MobaXterm自带的终端或者Windows的PowerShell都行：

bash复制ssh-keygen -R 192.168.x.x

把命令里的IP替换成实际虚拟机IP。清理完再连接，MobaXterm会像第一次连接那样弹出确认指纹的对话框，接受即可。

这里顺带提醒一句：如果重装了CentOS系统，但VMware里的网卡配置没变，IP地址可能还是原来的。这时候MobaXterm就会遇到“指纹变了”的提示，并不是什么复杂故障，清理指纹就好了。

5. VMware网络底层的大坑与恢复手段

5.1 NAT模式突然失效的处理

还有一种情况是：之前一直连得好好的，某天突然连不上了，虚拟机里ip addr看IP也正常，但Windows就ping不通，MobaXterm也连不上。这通常是VMware的虚拟网络组件出了问题。

VMware的NAT模式依赖宿主机上的VMware NAT Service（Vmware NAT Service）服务，以及VMnet8虚拟网卡。这两个组件任何一个异常，都会导致虚拟机网络不通。

第一步，打开VMware的“虚拟网络编辑器”，点击“更改设置”，查看VMnet8那一行，确认“NAT模式”被勾选。如果一切看着都正常，直接点击“还原默认设置”。VMware会卸载并重新创建所有虚拟网卡和网络服务，这一步能解决绝大多数NAT模式异常。

第二步，如果还原默认设置后还是不行，检查Windows服务。按Win+R输入services.msc，找到VMware NAT Service，确认状态是“正在运行”，启动类型是“自动”。如果服务没有运行，右键启动；如果启动类型不是自动，改成自动并启动。

VMware NAT Service的作用是把虚拟机的流量转发到宿主机真实网卡，它挂了，虚拟机即便有IP也上不了网，宿主机也连不上虚拟机。

5.2 Windows下VMware服务被禁用

这里专门说说服务被禁用这件事。Windows系统经常会被一些“优化软件”或者“安全管家”清理，把VMware的服务从自动改成手动甚至禁用。等到要用虚拟机的时候，网络就是不通，原因就在这里。

关键的VMware服务主要有三个：

• VMware NAT Service：负责NAT模式的流量转发。
• VMware Authorization Service：负责VMware的权限管理。
• VMware DHCP Service：负责给虚拟机分配IP地址。

建议这三个服务都设置成自动启动。打开services.msc，分别找到这三个服务，右键属性，把启动类型改成“自动”，然后点击“启动”。

我之前遇到过一台机器，Windows自动更新之后，VMware NAT Service被设置成手动启动。结果每次开机后虚拟机都没法上网，必须手动去服务管理器里把服务拉起来。后来把启动类型改成自动，重新用虚拟网络编辑器“还原默认设置”重装了一遍驱动，问题才彻底解决。

5.3 桥接模式连不上的判断方法

如果VMware用的是桥接模式，连不上还有一种单独的排查路径。桥接模式下，虚拟机相当于局域网里的一台独立机器，需要和宿主机在同一网段，共享局域网的网络。

桥接模式连不上的常见原因有三个：

第一，局域网没有DHCP服务，虚拟机获取不到IP。这种情况在个人家庭网络里比较少见，但在公司办公室网络或者一些实验网络里经常遇到。解决办法是在虚拟机里手动配置静态IP，网段要和宿主机一致，网关和DNS也要设成和宿主机一样的值。

第二，VMware Bridge Protocol（VMware桥接协议）没有绑定到真实的物理网卡。可以在Windows的“网络连接”里，找到真实网卡，右键属性，查看“VMware Bridge Protocol”这个组件是否勾选。如果没有勾选，桥接模式必然不通。

第三，IP冲突。桥接模式下虚拟机的IP如果和局域网里其他设备撞了，结果是时通时不通，让人非常难受。这种情况比较难排查，要一个一个ping看看有没有重复IP的设备。

我的建议是：除非有特殊需求，否则本地学习阶段直接使用NAT模式。NAT模式的网络隔离性好，不依赖局域网环境，不容易出现桥接模式的这些问题。

6. 错误提示速查表与实战避坑心得

6.1 常见错误提示速查表

为了方便大家以后遇到问题快速对照，我把常见的错误提示、可能原因和解决方法整理成了一个速查表，可以直接收藏。

6.2 我踩过的几个典型深坑

写下这篇文章的时候，我回想了一下这些年实际踩过最深的一个坑：有一次帮同事排查一台CentOS 7虚拟机连不上的问题。MobaXterm一直在报“Connection timed out”，我在虚拟机里查了ip addr，IP正常，SSH服务正常运行，防火墙也是关闭状态，Windows也能ping通虚拟机。理论链路都是通的，但就是连不上。

最后排查了半天才发现，问题出在Windows的防火墙。Windows自带的防火墙在连接虚拟机时，弹了一个“是否允许VMware服务通过”的提示，同事点了“取消”。结果Windows防火墙在后台拦住了所有到虚拟机IP的流量，MobaXterm自然连不上。在Windows的“允许应用通过防火墙”设置里，把VMware相关的条目重新勾选之后，问题瞬间解决。

这个坑说明一个道理：排查网络问题的时候，不要只盯着虚拟机这一侧，Windows的防火墙、服务、虚拟网卡驱动都是要检查的对象。尤其是Windows更新或者VMware升级之后，虚拟网络的底层状态很可能已经变了。

6.3 给新手的排查顺序建议

最后分享一套我自己一直沿用的排查顺序，遇到MobaXterm连不上虚拟机的时候，按这个顺序来，能省掉大半时间。

第一步，先看错误提示，判断问题方向。Connection refused、timed out、permission denied，方向完全不同。

第二步，确认虚拟机IP。进CentOS执行ip addr，确保有IP且是VMnet8同网段。

第三步，Windows ping虚拟机IP。ping不通，去查VMware虚拟网络编辑器、vmnet8网卡、VMware服务；ping得通，进入下一步。

第四步，检查虚拟机sshd状态。systemctl status sshd，没启动就启动，没安装就装上。

第五步，确认防火墙和SELinux状态。开着就先临时关闭测试，能连上再决定放行端口还是保持关闭。

第六步，检查MobaXterm会话配置。协议、IP、端口、用户名、密码，五个要素逐一核对。

这套顺序看起来简单，但它能在最短时间内把问题范围收紧。新手容易犯的错就是跳过前五步，直接卡在第六步反复折腾。

另外，练手阶段建议给虚拟机拍摄快照。改系统配置、调整网络设置之前先拍个快照，出问题了一键还原，比什么都好使。MobaXterm连接虚拟机这件事本身不难，难的是养成有条理的排查习惯。把这套思路记下来，换个Xshell、FinalShell、PuTTY，遇到同样的问题你也能照着查。