RHCE实验环境搭建与SSH远程管理实战指南

1. 谈RHCE实验，先把“考试题”翻译成“真场景”

1.1 认识RHCE考试的“操作题”本质

RHCE这个认证，圈内讨论度一直很高，但很多人的准备方式从一开始就跑偏了。有人抱着题库从头背到尾，有人只看视频里老师敲命令，真正到了实验环境里，手一放上键盘就卡壳。原因很简单：RHCE考的不是记忆，而是你在一个真实运行的系统上，能不能把活儿干完、干对、干到可验证的程度。

RHCE考试全是操作题。考试会给你一套已经装好的系统环境，里面可能有控制节点、被管理节点，你需要按题目要求完成网络配置、用户管理、服务部署、自动化脚本等任务。机器最后按结果打分，不看过程是否“像标准答案”。这意味着你学习的唯一可靠方式，就是在自己的实验环境里把这些任务真的做一遍。

所以“实验1”不是某个作业的编号，而是整个备考体系的地基。地基如果只是装好一台虚拟机、能开机看见桌面，那远远不够。你需要的是：一套稳定可复用的实验环境、一套能让你快速恢复现场的快照机制，以及一个“按真实任务来拆解知识”的学习习惯。这篇文章要解决的，就是这三件事里的第一件和第二件，顺带把第一个核心实验——SSH远程管理——完整跑通。

1.2 虚拟化环境选型：不是越贵越好，关键是还原真实场景

搭建RHCE实验环境，最常见的问题是有人一上来就追求“高配”。新买的服务器、多台物理机、复杂的网络布线，听着很专业，实际大部分时间都在折腾硬件，而不是在练配置。我的建议很直接：第一步用桌面上免费的虚拟化软件就够，三台虚拟机完美覆盖绝大多数考试场景。

三种常见方案我简单对比一下：

我见过很多人纠结“虚拟机会不会和真实服务器差太多”，这个担心可以放下。考试考的本来就是配置逻辑，不是硬件性能。你在虚拟机里能完成的网络配置、SSH加固、服务部署、自动化批量操作，换到真实服务器上同样成立。真正重要的不是物理还是虚拟，而是你有没有把实验当成真实任务来对待。

资源分配上，三台虚拟机没必要都开高分屏、大内存。我个人习惯是控制节点给2GB内存、20GB磁盘，两个被管理节点同样配置。如果宿主机器内存紧张，控制节点降到1.5GB也能跑，只要别同时跑三个重型服务就行。磁盘建议用动态分配而不是固定分配，避免一装完就吃掉几十GB空间。

1.3 一个“实验化”的学习习惯：把每个知识点变成可复现的任务

很多人学Linux的习惯是：看视频、记笔记、背命令。这套流程到考试前会发现一个问题——命令记住了，但题目换个问法就懵了。比如把“配置SSH禁止root登录”改成“确保root用户无法通过SSH远程登录”，如果你只是背过PermitRootLogin no，不会想到还要检查公钥文件、SELinux标签、防火墙规则，那就很可能丢分。

所以从实验1开始，我强烈建议你换一种方式：每个知识点都拆成一个“任务描述 + 完成动作 + 验证结果”的结构。任务描述要尽量向真实场景靠拢，比如“某公司要求管理员不能直接用root远程登录，但允许普通用户通过密钥方式登录”；完成动作就是你自己在虚拟机里一步步操作；验证结果不是看一眼“好像成了”，而是用命令证明状态确实符合要求。

当年我陪A同学备考时，他每天就练45分钟，但每次练完都会把三条东西写进一个文本笔记：目标是什么、我改了什么、我怎么证明它生效了。坚持了两周后，他对环境的熟悉程度明显比那些“周末突击一整天”的人扎实得多。这条习惯建议你从现在就开始，后面每个实验我都会按这个思路来拆解。

2. 第一套实验环境：三台机器怎么搭最容易踩坑

2.1 拓扑先把角色分清楚，别一台机器打天下

实验环境我建议至少三台机器，而不是一台。原因在于RHCE考试里有大量任务涉及“从一台机器操作另一台机器”的场景：你要在控制节点上生成密钥、下发配置，在被管理节点上确认服务状态。只有一台机器，你永远练不出这种跨节点的操作手感。

这套拓扑可以这样规划：

• 控制节点（control）：你的操作入口，负责发起SSH连接、跑脚本、后期还可以安装自动化管理工具。
• 目标节点A（node-a）：被管理机器，用来完成各种服务配置类实验。
• 目标节点B（node-b）：第二台被管理机器，用来验证批量部署、多机协作类任务。

网络模式上，我建议至少让目标节点A和B在同一个内部网段，控制节点通过一个可上网的NAT网络访问它们。这样做既符合真实办公环境的“内外网分离”感觉，也方便你练习固定IP、主机名解析这些基础操作。

很多人一开始会偷懒，三台机器全部用默认的DHCP自动获取地址。这样能开机联网，但对实验来说是个隐患。DHCP分配的地址重启后可能变化，一旦你写死在某个配置里，下次开机就连不上了。服务器场景里几乎没有长期用动态地址的道理，所以RHCE实验从第一天就该用静态IP。

2.2 系统装完先做三件事：固定IP、改主机名、配解析

系统安装的过程这里不详细展开，大部分图形化安装向导都能顺利走完。真正容易踩坑的，是装完系统进入命令行之后，发现网络根本不通。这一步最常见的现象是：ping外网没反应，ip addr看不到有效地址，网卡显示处于未激活状态。

如果你是第一次用命令行配网，建议先把网卡名看清楚。执行ip link或者nmcli device status，找到实际网卡名。不同机器可能不一样，别想当然写成 eth0。找到网卡后，用nmcli把它配置成静态IP的方式比较直观：

# 假设网卡名为 ens160，静态IP为 192.168.56.11，网关和掩码按你的虚拟网络调整 nmcli connection modify ens160 ipv4.addresses 192.168.56.11/24 nmcli connection modify ens160 ipv4.gateway 192.168.56.1 nmcli connection modify ens160 ipv4.dns 192.168.56.1 nmcli connection modify ens160 ipv4.method manual nmcli connection up ens160

改完执行ip addr看一下地址是否生效，再ping一下网关。这里有个常见误区：有些人改了配置文件但忘了重新激活连接，结果地址没变。用nmcli connection up重新激活一次，很多“配置不生效”的问题就解决了。

固定IP之后，紧接着要做的是修改主机名。考试和真实环境都要求你能通过主机名区分机器，而不是靠记住IP。修改方式很简单：

hostnamectl set-hostname control hostnamectl set-hostname node-a # 在对应机器上执行 hostnamectl set-hostname node-b

然后编辑/etc/hosts，把三台机器的主机名和IP对应关系写好。在实际生产环境里，我更推荐用内部DNS做解析，而不是到处改hosts文件。但在实验环境里，用hosts快速打通节点间解析是最省事、最不容易出错的做法。你可以在控制节点上执行一次ping node-a验证解析是否正常。

2.3 SSH免密：从“人能连”到“程序能连”

环境搭建的最后一步，是让控制节点可以免密SSH登录两台目标节点。这一步太关键了，后面自动化实验几乎全部依赖它。你不可能每次都手输密码去操作另一台机器，那是人肉运维，不是工程化思维。

在控制节点上生成密钥对：

ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa

-N ""表示空口令，-f指定密钥文件路径，这样生成过程完全不用交互。然后把公钥拷贝到目标节点：

ssh-copy-id root@node-a ssh-copy-id root@node-b

第一次连接会提示确认指纹，输入yes，接着输入目标节点的root密码即可。完成后再执行ssh node-a，应该能直接登录而不需要密码。这一步如果失败，常见原因有三个：目标机SSH服务没启动、防火墙拦了22端口、或者你输错密码。建议从这三条按顺序排查。

提示：免密配置好后，先不要急着删掉密码登录途径。你还需要密码作为“后门”，方便后面实验出错时能从控制台恢复。等所有实验都稳定了，再考虑收紧认证策略也不迟。

3. 第一个核心实验：SSH远程管理服务从配置到加固

3.1 为什么SSH是所有自动化实验的地基

很多人觉得SSH不过就是个远程登录工具，没什么好练的。这种想法会在一开始埋下大坑。RHCE考试里，你几乎每一个操作动作都是从控制节点发起SSH到目标节点执行的。如果你的SSH连接不稳定、不理解SSH的认证机制、不会调整服务端配置，后面做任何服务部署实验都会卡在第一步。

更重要的是，SSH不仅承载“人”的操作，还承载“程序”的操作。自动化工具、脚本、批量分发配置，这些无一例外都依赖SSH通道。把SSH当作第一个研究对象，其实是在给整个实验体系打地基。

这个实验我会拆成几个层次，先从服务端配置开始，然后处理防火墙和SELinux的影响，最后教你用几条命令验证整个链路是否真的通。做完这个实验，你应该能做到：修改SSH服务端行为后，重启或重载服务不会把自己锁在门外，并且能从控制节点稳定、安全地连到所有目标节点。

3.2 服务端配置改什么、不改什么，心里要有数

SSH服务端的配置文件在/etc/ssh/sshd_config。修改之前，一定先备份：

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

接下来按实验需求调整几个重点参数。以“禁止root直接登录、仅允许密钥认证、自定义端口”场景为例：

Port 2222 PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no

这四个参数分别控制监听端口、root登录限制、公钥认证开关、密码认证开关。我要特别提醒：PasswordAuthentication no一定要等你的密钥认证验证通过了再改。很多人先关了密码登录，然后发现自己还没把公钥配好，等断线重连时直接被锁在门外，只能去虚拟机的控制台里抢救。

改完配置，不要直接重启服务。先用语法检查命令验证一下：

sshd -t

这条命令不会输出任何正常信息，如果配置文件有问题它会直接报错。确认没问题再执行重载：

systemctl reload sshd

这里用reload而不是restart，是有讲究的。restart会短暂断开所有正在进行的SSH连接，而reload只会让服务重新读取配置，不影响已有连接。你可能不觉得这有多重要，等你在生产环境操作时就会明白，一个restart能制造多大的事故。

3.3 防火墙与SELinux的“隐形影响”，以及完整验证链

改完端口到2222之后，你会发现从控制节点连接默认端口还是通的，或者新端口连不上。原因在于：SSH服务本身可能还在监听22端口，或者防火墙根本没放行2222。

先用ss -tlnp | grep sshd看一下sshd到底在监听哪个端口。如果你已经改配置并重载了服务，这里应该能看到2222的监听。如果还是22，说明配置没生效或者你改错了配置文件。

然后处理防火墙规则。不同系统的防火墙管理命令有区别，但思路一致：放行新端口、拒绝旧端口。以常见命令风格为例：

firewall-cmd --permanent --add-port=2222/tcp firewall-cmd --reload firewall-cmd --list-all

这一步做完，再从控制节点用新端口连接试试。这类放行操作最大的坑在于：忘了加--permanent，导致规则只对当前会话有效，重启后所有规则全部丢失。

防火墙之外，还有一个很容易被忽略的东西：SELinux。默认情况下，SELinux会限制SSH使用的端口集合。如果你改了端口但没告诉SELinux，即使防火墙放行了，连接也可能会被拒。

查看当前SELinux对SSH端口的放行情况：

semanage port -l | grep ssh

如果列表里没有2222，就需要添加：

semanage port -a -t ssh_port_t -p tcp 2222

这一条命令经常被备考的人忽略，因为平时SSH用的都是默认22端口，根本不会触发SELinux限制。但考试和真实运维中，改端口是安全加固的常见要求，所以这一步值得你亲手做一遍。

完整的验证链应该是这样的：

# 从控制节点发起连接 ssh -p 2222 用户@node-a # 在目标节点上确认服务状态 systemctl status sshd # 确认监听端口 ss -tlnp | grep sshd # 确认防火墙规则 firewall-cmd --list-all # 确认SELinux放行 semanage port -l | grep ssh

任何一环缺失，都可能让你从“看起来配好了”变成“实际一测就挂”。

注意：实战中修改安全配置时，“最小改动原则”永远适用。一次只改一个参数，验证通过后再改下一个。别把端口、密码登录、root登录三个改动一次性全堆上去，出了问题你根本不知道是哪一步导致的。

4. 实验做完怎么确认“我真会了”？三个验证动作

4.1 破坏性测试：重启用事实说话，而不是凭感觉

配置完成后，大多数人会做一次连接测试，通了就觉得实验做完了。这种验证太“温柔”，不足以证明你真的掌握了。我习惯用破坏性测试来确认状态。

第一个动作是重启目标节点。虚拟机里执行reboot，等它重新起来后，从控制节点用ssh -p 2222重新连接。这一步能暴露很多问题：如果IP变了、SSH服务没设开机自启、防火墙规则没持久化、SELinux策略没保留，重启后就会立刻现形。能够扛住重启的配置，才算真正写进了系统。

第二个动作是故意制造故障然后修复。比如说，把目标节点的公钥文件权限改成777，再用SSH连接，大概率会报Permissions too open之类的错误。这时候你会被迫去理解权限为什么重要、应该改成什么值才对，而不是只会一键复制粘贴命令。

我建议你把“故意搞坏再修好”当成标准练习流程，尤其是对权限、防火墙、SELinux这类容易“隐性生效”的东西。只有亲眼见过故障的报错信息，你以后真遇到问题时心里才有底。

4.2 一个SSH连不上的完整排查链路，比一百条经验有用

实验过程中你一定会遇到连不上的情况，这是好事。我想给你展示一条标准的排查链路，以后遇到类似问题，不用瞎猜。

假设的现象是：控制节点能连上node-a，但连不上node-b，报错是Connection timed out。

排查步骤我习惯从最底层链路开始，一层层往上看：

1. 先确认网络通不通：在控制节点执行ping node-b。如果ping不通，问题在网络配置、IP或主机名解析上，而不是SSH服务上。
2. 确认目标端口能不能通：执行nc -vz node-b 2222（或对应工具的探测命令）。如果端口不通，继续看防火墙和服务监听状态。
3. 确认sshd服务状态：在node-b上执行systemctl status sshd。如果服务挂了，先看日志里为什么挂。
4. 确认防火墙规则：执行firewall-cmd --list-all，看2222端口是否真的放行。这一步最容易发现问题。
5. 确认SELinux放行：执行semanage port -l | grep ssh，看新端口是否在许可列表里。

当时A同学遇到的情况就是卡在第4步：他在node-a上放行了新端口，node-b上的防火墙规则忘了加。从现象看，两台机器配置几乎一样，但一个通、一个不通，很容易让人怀疑是系统问题。按链路一查，五分钟就定位了。

排查的关键原则是每次只改一个变量，改完重新测试。最怕的是同时把IP改了、防火墙规则重写了、密钥重新生成了一遍，最后通了也不知道是哪一步让它通的。

4.3 把第一个实验串进自动化闭环，才算是真正入门

SSH实验做完后，你可以顺手做一个延伸练习：在控制节点上写一个简单的循环，批量检查所有机器的SSH连接状态，或者批量执行同一命令。伪代码思路是：

for host in node-a node-b; do ssh -p 2222 "${host}" "hostname; uptime" done

如果这条循环能顺利跑通，说明你已经具备“从控制节点统一操作多台机器”的能力。而这一步，恰恰是RHCE体系中自动化相关内容的入口。后面的实验再往里加真正的批量配置工具时，底层的SSH通道你已经不再陌生，学习曲线会平缓很多。

到了这里，“实验1”的核心目标就达成了：环境可复用、SSH安全可控、整个链路能被命令验证，并且你能从控制节点单手操作多台机器。这套能力搭建起来之后，再进入用户管理、软件安装、网络服务配置这些实验，你会发现自己不会再被“连不上”“找不到配置文件”这些问题反复打断。

说点我个人的体会。接触过不少备考的人，我发现最后通过与否的差距，往往不是谁记住的命令多，而是谁能在出错时快速定位问题。RHCE实验最值钱的部分，恰恰是那些失败的连接、超时的端口、被SELinux拦下的请求——你解决得越多，越接近一个真正能上手干活的运维人员。所以别怕把环境搞坏，坏一次修好一次，你的理解就深一层。这套实验环境值得你多用几周，直到“改配置、验证、回滚”变成肌肉记忆为止。