RHEL9虚拟机部署与SSH远程登录安全加固实践-育师

1. 为什么我把RHEL9装在VMware虚拟机里

最近整理了一套基于RHEL9的虚拟机部署和SSH远程登录流程，写出来给准备入门Red Hat系Linux、或者正在备考RHCSA、又或者只是想在本地搭一套稳定开发环境的朋友。整个流程包含三块：在VMware Workstation里创建RHEL9虚拟机、完成系统安装和基础网络配置、再通过SSH从Windows/macOS/Linux主机远程登录并做安全加固。没有高深理论，全部是我实际敲过的命令、点过的界面和踩过的坑。

先说结论：现阶段想在个人电脑上学习RHEL9，最省心的方案就是VMware Workstation Pro配RHEL9 DVD镜像。过去这软件要收费，但VMware被Broadcom收购以后，Workstation Pro对个人用户已经免费，下载一个安装包就能用。比VirtualBox的易用性、稳定性、快照管理都要好一些，尤其在3D图形加速、USB设备透传、拖拽复制这些细节上体验明显。你如果已经装了VirtualBox，那也能跑RHEL9，只是部分显卡和剪贴板共享功能得自己折腾，相比之下VMware更省时间。

为什么非要虚拟机而不是直接装到物理机或者用云主机？理由很简单：虚拟机可以随时打快照，装坏了、配置改崩了，一键回滚就能恢复。RHEL9的很多系统级改动，比如SELinux策略、firewalld规则、sshd配置，都可能把机器弄到起不来，你在物理机上这么折腾一次至少浪费半天，在虚拟机里两分钟就能重来。加上虚拟机网络隔离特性，SSH、NFS、DNS、DHCP这些服务都能模拟出多机环境，做实验比云主机方便太多。

RHEL9和CentOS Stream 9是当前Red Hat系的两个主要方向。RHEL9追求稳定，每个大版本支持十年，所以企业生产环境大量用它；CentOS Stream则是滚动更新的上游版本，适用于喜欢追新的人。RHEL9本身需要订阅，但对个人学习有免费方案，后面会专门说。这套手册就是围绕RHEL9展开，所有命令默认在9.3/9.4版本上测试过。

1.1 这套方案适合谁

刚接触Linux、之前只用过Ubuntu或CentOS 7，想试试企业级发行版的人。
准备考红帽认证，需要在本地复现官方练习环境的人。
开发或运维工作中要跟RHEL系服务器打交道，想自建测试环境的人。
对这些没需求，但手里有旧电脑，想装个轻量级Linux系统跑服务的极客。

1.2 为什么不用云服务器或直接物理机安装

云服务器最大的坑是费用和网络隔离。按小时计费的机器，挂一晚上忘了关机，账单就上去了。而且云主机的网络策略、安全组、防火墙层级太多，本来只是想练一个SSH登录，结果半天都卡在安全组规则上。物理机安装的问题是来回切换系统很麻烦，RHEL9对硬件驱动的检测虽然好，但总有一些冷门网卡或者双显卡笔记本在安装界面黑屏，虚拟机反而没这么多兼容性问题。

虚拟机还有一个隐藏优势：快照配合克隆，可以快速生成一组互相能Ping通的独立节点。比如你想练Ansible，控制端一台，被管端两台，克隆三个RHEL9虚拟机出来，一分钟就搭好环境。物理机和云主机都做不到这么灵活。

2. 部署前的准备工作

2.1 RHEL9安装镜像怎么获取

RHEL9的ISO镜像不能像Ubuntu那样直接从官网公开下载，需要先在Red Hat官网注册一个账号，然后到Red Hat Developer Subscription页面订阅开发者计划。这个订阅对个人开发者免费，允许在本地和公共云上运行最多16个节点的RHEL，虽然不带电话支持，但用来学习和测试完全足够。实测注册过程只需要一个邮箱，不需要公司信息，也不需要绑定信用卡。

登录开发者后台以后，在Downloads页面选择Red Hat Enterprise Linux 9.x版本，下载DVD ISO镜像就可以。注意选x86_64架构，如果电脑是Apple Silicon芯片，那VMware里装的其实是ARM版本的RHEL，镜像换成aarch64即可。文件大概5~6GB，建议用支持断点续传的下载工具拉取，国内直连有时候会慢，但一般不会断。

这里有个容易忽略的点：RHEL安装完成后需要执行subscription-manager register把系统注册到Red Hat账号，否则软件源不可用，yum install什么都装不了。开发者订阅注册以后，RHEL9就可以正常从官方源更新软件包。第一次注册时要保证虚拟机能访问外网，网络配置最好在安装时就把NAT模式给定下来。

2.2 VMware Workstation中创建虚拟机的关键参数

创建虚拟机我推荐选“自定义（高级）”，不要用推荐安装。因为推荐安装会默认创建一个20GB的磁盘，RHEL9安装完加上软件包更新很快就满了，回头扩容又是一顿折腾。下表的参数是实测比较稳的底配，如果你的宿主机内存和硬盘充足，建议在表中基础之上再加。

项目	推荐配置	说明
兼容性	Workstation 16/17.x	新版虚拟硬件支持更好
客户机操作系统	Red Hat Enterprise Linux 9 x64	VMware已内置识别
CPU	2核	安装时建议给2核以上
内存	4096MB	低于2GB会让安装很卡
磁盘	60GB	分配虚拟大小，立即分配全部空间需谨慎
网络适配器	NAT	初学者首选，主机可访问虚拟机和外网
固件	UEFI	RHEL9默认支持UEFI安全启动
I/O控制器	LSIGeneric SCSI或NVMe	性能差别不大

创建完成后先别急着启动，点“编辑虚拟机设置”，在CD/DVD里挂载刚才下载的RHEL9 ISO，勾选“启动时连接”。如果不想占太多物理磁盘空间，可以取消“立即分配所有磁盘空间”，选择“将虚拟磁盘存储为单个文件”，实际使用时再按需扩展。

RHEL9在安装过程中默认会尝试访问网络安装源，如果虚拟机暂时没有网络，别怕，选择“自动配置分区”和本地介质安装即可，后续再补网络配置。

2.3 安装前的一个提醒：网络模式选NAT还是桥接

很多人在这一步纠结。NAT模式下，虚拟机通过宿主机共享IP地址访问外网，对外表现为宿主机的一个进程，宿主机和虚拟机之间也天然互通，不受外部路由器影响，适合学习场景。桥接模式下，虚拟机就像局域网里的独立设备，由路由器直接分配IP，跟外部设备能互相访问，但容易受到办公室网络环境限制，比如没有DHCP、MAC地址绑定、Wi-Fi路由器隔离客户端，导致虚拟机连不上网。

推荐初学者第一次就用NAT，因为SSH练习在NAT模式下完全够用：宿主机能SSH到虚拟机，虚拟机也能SSH到宿主机，甚至两台NAT模式虚拟机之间都可以互通。等以后需要别人从外部访问虚拟机时再切换桥接，并配静态IP。

3. RHEL9安装全过程详解

3.1 安装引导与基础配置

虚拟机启动后，看到黑底欢迎界面，第一项是“Test this media & install”，第二项是“Install Red Hat Enterprise Linux 9.x”。如果ISO是刚刚下载校验过的，直接选第二项Enter，省掉介质检测时间。如果镜像来源不干净，建议选第一项，检测失败宁可不用。

进入图形安装界面后，第一步是选择语言，建议保持英文。因为RHEL后续的日志、软件包描述、命令行输出大部分都是英文，安装界面中文切换过来以后，遇到报错反而看不懂。操作系统内部设置语言的选项可以在“Language Support”里加中文支持，但系统语言最好还是英文。

接下来会进入“Installation Summary”主界面。这个页面是安装的核心枢纽，有几个入口必须处理：

安装目的地：选择虚拟机那块虚拟磁盘。布局不用太复杂，底层LVM或标准分区都行。我用的是自动分区，它会自动创建/boot、根分区和swap，对学习场景非常省事。如果你想手动分，建议/boot给1GB，/给50~80GB，swap按内存大小给4GB左右，/home可选。
软件选择：初学者建议选“Server with GUI”，这样系统带图形桌面，上手成本低。如果只想要黑色终端，选“Minimal Install”，安装完体积小，启动快。对我来说，Minimal Install更接近生产环境，也逼着自己熟悉命令行。
Root密码：RHEL9默认禁止root通过SSH直接登录，你只能先用普通用户登录，再su或sudo切换root。设置root密码时强度必须够，如果太简单，安装程序会提示确认，不建议跳过。
创建用户：必须创建一个普通用户，勾选“Make this user administrator”让他加入wheel组，这样才可以用sudo。这个用户名的密码务必记住，SSH登录和日常操作都要用。

以上设置完成后，点“Begin Installation”。安装过程大约10~20分钟，时间取决于磁盘性能和CPU算力。出现“Complete”提示后点Reboot。

3.2 安装过程中常遇到的意外情况

黑屏或卡在启动画面。常见于VMware的显卡兼容性问题。先试试在虚拟机设置里把“加速3D图形”打开，或者关闭“安全启动”。另一种情况是ISO引导和内核冲突，改用DVD完整镜像而不是boot.iso。安装完成后进入系统出现黑屏，按Ctrl+Alt+F2切到文本终端界面处理，再回头调显卡驱动。

提示找不到安装源或root设备。一般是因为磁盘控制器类型不当。回到虚拟机设置，把SCSI控制器型号从LSI Logic改成VMware Paravirtual SCSI，或改为NVMe，重新挂载ISO再启动。

安装进度卡在67%左右。大多是网络源检测超时，比如你勾选了网络安装源但虚拟机连不上外网。重启安装，在“安装源”里改成“Auto-detect”或者关闭网络源，只用本地镜像。

3.3 首次开机后的系统基础设置

重启完成后系统进入initial setup。这里建议把系统订阅注册做完，否则安装软件会有麻烦。

subscription-manager register --username=你的RedHat账号 --auto-attach

注册成功后，不做任何配置就能使用AppStream和BaseOS这两个官方仓库。实测执行dnf repolist确认一下，能看到两个仓库就说明订阅OK。网络如果还没通，这一步会失败，所以先确保网络配置正确再注册。

如果安装时选了最小化，系统会直接进入命令行登录界面，用普通用户登录，然后用sudo su -切换到root。建议先更新一遍缓存：

sudo dnf makecache sudo dnf upgrade -y

升级过程中内核有更新，后面重启后系统就完全就绪了。这时候你面对的是一个裸RHEL9，还没开启SSH服务，接下来就是网络和SSH的重头戏。

4. 网络配置与SSH服务端部署

4.1 三种虚拟网络模式对比

在配置之前，先把VMware的三种网络模式搞清楚，因为SSH连不上时你会反复确认这里的设置。

模式	虚拟机能否访问外网	宿主机能否访问虚拟机	虚拟机之间互通	使用场景
NAT	能	能	能	学习、测试、单机开发
桥接	能	能	能	需要外部设备访问虚拟机
仅主机	不能	能	能	完全隔离实验

初次使用NAT最省心。VMware的NAT模式有一个虚拟子网，默认类似192.168.136.0/24，网关是192.168.136.2，DHCP会从128到254之间分配地址。宿主机能访问到虚拟机是因为VMware虚拟网卡VMnet8连接着这个内网。你在VMware的“编辑——虚拟网络编辑器”里能看到NAT网段。

4.2 把NAT模式下的IP固定下来

NAT模式下虚拟机默认通过DHCP获取IP，每次重启可能会变。如果IP变了，SSH配置、后续的Remote-SSH客户端都得跟着改，非常烦。所以装完系统第一件事就是改成静态IP。

先查看网卡名和当前连接状态：

ip addr show nmcli con show

RHEL9默认网络接口名类似ens160、ens192，具体名称跟VMware虚拟网卡驱动有关。记住这个连接名称，比如“System ens160”。用nmtui或nmcli配置都可以。如果你不习惯terminal操作，执行nmtui打开图形化文本界面，选“Edit a connection”，回车进入编辑：

IPv4方：Manual
Address：192.168.136.100/24
Gateway：192.168.136.2
DNS Server：192.168.136.2
需要时网关只填一个地址。

保存后执行nmcli重新加载连接：

sudo nmcli con down "System ens160" sudo nmcli con up "System ens160"

命令行方式也可以，而且适合写脚本批量操作：

sudo nmcli con mod "System ens160" ipv4.method manual ipv4.addresses 192.168.136.100/24 ipv4.gateway 192.168.136.2 ipv4.dns 192.168.136.2 sudo nmcli con up "System ens160"

改成静态IP后，测试连通性：

ping -c 4 192.168.136.2 ping -c 4 www.redhat.com

如果能通外网，说明NAT网关和DNS都没问题。这里有个经验：如果外网ping不通但网关能通，检查DNS，因为NAT模式的路由一般不会被防火墙堵住，DNS解析不出去才是多数原因。

4.3 开启SSH服务并放行防火墙

RHEL9默认安装好了OpenSSH服务端，只是没有启动。开启命令是：

sudo systemctl enable --now sshd sudo systemctl status sshd

看到Active: active (running)就说明服务起来了。再用ss确认端口监听：

ss -tlnp | grep :22

RHEL9默认启用了firewalld，好在firewalld自带ssh服务规则。检查一下：

sudo firewall-cmd --list-all

如果结果里有services: ssh这一项，说明22端口已经放行。万一没有，手动添加：

sudo firewall-cmd --add-service=ssh --permanent sudo firewall-cmd --reload

这里还有一个隐蔽点：SELinux。RHEL9强制开启SELinux，但sshd的默认策略是允许监听22端口和普通用户登录的，一般不用额外配置。如果今后你修改了SSH端口到2222，就不仅要改防火墙，还要执行：

sudo semanage port -a -t ssh_port_t -p tcp 2222

否则sshd能启动但连不上。新版本的selinux-policy和semanage工具默认没装，需要dnf install policycoreutils-python-utils。这个坑我踩过，改端口的朋友重点记住。

4.4 先做一次本地SSH登录验证

在宿主机上打开命令行工具，Windows用CMD或PowerShell，macOS/Linux用终端：

ssh 你的用户名@192.168.136.100

首次连接会看到提示确认host key指纹，输入yes回车，然后输入用户密码。能登录就说明服务端这层已经通了。第一遍测试不要用root，RHEL9从OpenSSH层面默认禁用root密码登录，后面会说怎么安全放开。

5. SSH会话管理、免密登录与安全加固

5.1 客户端工具怎么选

SSH登录不只是黑窗口敲命令这么简单。实际使用中，你会发现一个好的客户端能显著提升效率。Windows用户常用的几类：

OpenSSH自带工具：系统自带，不用装额外软件。支持ssh、scp、sftp、ssh-keygen，但界面朴素，要自己记命令。
MobaXterm：自带本地终端、多标签、SFTP文件管理器，集成X11转发，远程打开图形界面方便，社区版免费。
Xshell：老牌终端，支持标签管理、脚本录制、服务器管理会话树，家庭和学校用户免费。
FinalShell：国产工具，自带实时资源监控和SFTP，上手门槛低。
VS Code Remote-SSH：开发者的最爱，后面单讲。

我个人主用VS Code Remote-SSH来做日常开发编辑，用MobaXterm做快速命令行管理。不要装一堆来路不明的所谓“绿化版”“汉化版”SSH客户端，工具自带的正版功能已经足够。你的密码、私钥都可能被套壳软件偷走。

5.2 配置SSH密钥免密登录

密码登录有个大问题：密钥强度低容易被暴力破解，每次登录还得输密码，输错就锁账号。所以远程登录的正确姿势是使用公钥认证。先在你自己的宿主机电脑上生成一对密钥，注意不是虚拟机上生成。

以Windows自带的PowerShell为例：

ssh-keygen -t ed25519 -C "rhel9-vm"

一路回车，会在C:\Users\你的用户名\.ssh\下生成id_ed25519（私钥）和id_ed25519.pub（公钥）。把公钥内容传到RHEL9虚拟机里，传统方法是ssh-copy-id，但Windows默认没有这个命令。你可以手动操作：

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh 你的用户名@192.168.136.100 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

这条命令会先让你输入一次密码，然后把公钥追加到虚拟机的authorized_keys文件里。完成后重新连接一次：

ssh 你的用户名@192.168.136.100

如果还能登录，但不再要密码，说明免密已生效。此时可以再用ssh -v加详细输出看到Authenticated to 192.168.136.100 (via publickey)这样的描述。如果你用的是macOS或Linux，直接执行ssh-copy-id即可：

ssh-copy-id -i ~/.ssh/id_ed25519.pub 你的用户名@192.168.136.100

密钥认证生效后有一个易犯错误：直接测试时私钥权限不对会报Permission denied。Windows的OpenSSH对私钥权限很敏感，不要在共享目录里放私钥。Linux/macOS必须把私钥权限改成600：

chmod 600 ~/.ssh/id_ed25519

5.3 修改sshd_config做安全加固

免密登录验证通过后，再回到虚拟机修改服务端配置，把SSH的安全性拉上来。编辑/etc/ssh/sshd_config，我通常建议这样改：

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo vim /etc/ssh/sshd_config

关键参数：

参数	推荐值	说明
Port	22	如改其他端口，记得防火墙与SELinux同步
PermitRootLogin	prohibit-password	允许root用密钥登录，禁止密码登录
PubkeyAuthentication	yes	开启公钥认证
PasswordAuthentication	no	关闭密码认证，杜绝暴力破解
MaxAuthTries	3	单次连接最多试3次
AllowUsers	你的用户名	只允许指定用户登录
ClientAliveInterval	300	每5分钟发一次心跳包防断线
ClientAliveCountMax	2	心跳无响应2次后断开

修改完先做语法检查：

sudo sshd -t

没有报错再重启：

sudo systemctl restart sshd

重启sshd不会断开你当前已建立的连接，所以可以放心把配置刷新。但关闭密码登录前务必确保密钥测试成功，否则你就把自己锁在外面了。这个操作顺序至关重要，先改配置再重启，如果发生致命错误，只能去VMware的虚拟机控制台用vSphere或Workstation的里终端界面改回来。

AllowUsers的好处非常明显，即使你的主机被人从公网扫到，非授权用户连用户名都提交不上。比如你配置AllowUsers zhangsan，那别人ssh lisi@192.168.136.100就会立刻被拒。

5.4 密钥失效和SELinux那点事

有时你明明把公钥加到authorized_keys了，但SSH还是提示公钥被拒。最常见的原因是家目录或.ssh目录权限不对。RHEL9里的严格规则是：

用户家目录不能对“其他用户”有写权限，比如chmod 755没问题，chmod 777就有问题。
.ssh目录权限必须是700。
authorized_keys文件权限必须是600。

修复命令：

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chown -R 你的用户名:你的用户名 ~/.ssh

如果权限都对，还不能登录，那查一下SELinux是否拦截了sshd对authorized_keys的读取。查看审计日志：

sudo ausearch -m avc -ts recent | grep sshd

有SELinux拦截记录时，执行：

sudo restorecon -Rv ~/.ssh

这条命令修复.ssh目录的文件安全上下文标签。修改过家目录路径或移动过公钥文件时特别容易出现这个情况，因为RHEL9要求sshd只能读取带sshd_key_t上下文标签的密钥文件。临时关闭SELinux虽然能解决，但我不建议，生产环境别这么干。

5.5 会话掉线和服务“自杀”之谜

很多人在本机用SSH连着服务器跑一个Node服务或者程序，然后关掉笔记本盖子，第二天发现服务停了。其实这不是SSH的问题，而是你通过SSH登录后启动的进程挂在当前shell会话下，终端会话一断开，SIGHUP信号就把进程带走了。解决思路有三种：

nohup绕过挂断信号：

nohup your_command > app.log 2>&1 &

tmux保持会话：用tmux建一个独立会话，即使SSH断开，进程也在tmux里继续跑。

tmux new -s mysession # 启动你的服务，然后按Ctrl+b d脱离会话 tmux attach -t mysession

用systemd托管服务：这是最规范的做法，把服务写成systemd unit，开机自启并自动重启，跟SSH完全无关。

此外，SSH连接长时间没操作，可能会被网络设备或服务端踢掉。在sshd_config里设置ClientAliveInterval 300，客户端设置ServerAliveInterval（Windows可以通过PowerShell的ssh -o ServerAliveInterval=60来指定），连接就不容易假死。

6. 客户端远程登录实操场景

6.1 无第三方工具的SSH登录

学习阶段尽量吃透原生命令，这样换一台电脑你依然能干活。在Windows PowerShell、CMD、macOS终端或Linux终端里，命令完全一样：

ssh 你的用户名@192.168.136.100

如果想指定不同端口、指定密钥文件：

ssh -p 2222 -i ~/.ssh/id_ed25519 你的用户名@192.168.136.100

要传文件，用scp或sftp。把本地a.txt传到虚拟机：

scp a.txt 你的用户名@192.168.136.100:/home/你的用户名/

把虚拟机里的b.log拉回本地：

scp 你的用户名@192.168.136.100:/home/你的用户名/b.log ./

对于不需要交互的批量任务，可以写一个小脚本。比如批量在多个服务器上执行命令察看磁盘空间：

for host in server1 server2 server3; do ssh 你的用户名@$host "df -h"; done

6.2 VS Code Remote-SSH搭建远程开发环境

如果你写代码，强烈建议把VS Code的Remote-SSH扩展用起来。它让你在本地的VS Code窗口里直接编辑虚拟机里的文件，运行终端也自动连接到远程，调试、补全、Git操作全都无缝。安装方法：

在VS Code扩展市场搜“Remote-SSH”并安装。
Ctrl+Shift+P打开命令面板，输入“Remote-SSH: Connect to Host”。
选择“Add New SSH Host”，输入你的用户名@192.168.136.100，再选一个ssh配置文件路径保存。
连接成功后，VS Code左下角会显示“SSH: 192.168.136.100”，打开远程文件夹，开始干活。

这里有一个国内用户经常遇到的问题：初次连接时VS Code会在远程主机上下载一个server包，进度显示“downloading server package 0 B”，然后卡住不动。这通常不是虚拟机防火墙问题，而是本地网络去访问外网的连通性差，或者DNS解析慢。你可以先在虚拟机上手动测试能否正常访问下载地址，比如curl一下https，能通就没问题。也可以编辑远程主机的~/.vscode-server目录权限，或者切换连接方式重试。大多数情况下，等待一会儿或重装一次Remote-SSH就能解决。别去轻信网上各种改“代理”方案的偏方，先从基础连通性排查。

6.3 用ssh config管理多台服务器

服务器一多，每次输入完整用户名和IP就很累。在客户端的~/.ssh/config（Windows是C:\Users\你的用户名\.ssh\config）里写好别名，以后直接ssh别名即可：

Host rhel9 HostName 192.168.136.100 User zhangsan Port 22 IdentityFile ~/.ssh/id_ed25519 Host rhel9-bak HostName 192.168.136.101 User zhangsan Port 22 IdentityFile ~/.ssh/id_ed25519

保存后直接测试：

ssh rhel9 scp test.txt rhel9:/tmp/

这段配置还能指定跳板机，比如所有服务器都必须从一台中转连过去：

Host internal HostName 10.0.0.10 User admin ProxyJump jump

不过初学者先别贪心，把基础配置和密钥认证搞定，再加入ProxyJump也不迟。

7. 常见问题与排查技巧实录

7.1 连接超时：第一种最经常发生的情况

现象：执行ssh后长时间没反应，最后报Connection timed out，或者提示“No route to host”。排查路径基本是：

先在宿主机Ping虚拟机IP，ping不通说明网络层就有问题。
再确认虚拟机IP还是不是刚才那个，因为DHCP可能重新分配了地址。用VMware的虚拟机控制台登录进去执行ip addr show看看。
接着查网卡是否启动。nmcli device status，如果status是disconnected，用nmcli device connect ens160。
在宿主机上测试端口是否通：Windows用Test-NetConnection 192.168.136.100 -Port 22，Linux/macOS用nc -vz 192.168.136.100 22。
如果端口不通但Ping通，问题多半在firewalld没放行ssh。

有一次我反复配置还是超时，最后发现是VMware的NAT服务被Windows安全策略禁了。解决办法是在服务管理器里找到VMware NAT Service和VMware DHCP Service，手动设为自动并启动。这个问题隐藏很深，症状跟网络配置错误一模一样。

7.2 认证失败：怎么找“钥匙不对”

现象：报Permission denied (publickey,password)。这个提示不区分密码错误、用户不存在或策略拒绝，是故意模糊的。

按以下顺序排查：

确认用户名拼写正确，whoami和id在虚拟机上核对。
检查是否用了正确的密钥。如果客户端有多个私钥，需要ssh -i明确指定。
用ssh -vvv查详细日志，可以看到client发送密钥、server返回拒绝的具体原因。
到虚拟机里查看journalctl -u sshd -f，服务端日志会写清楚“Failed publickey for user”，原因要么是权限问题，要么是用户名不在AllowUsers里。
检查~/.ssh/authorized_keys内容是否完整，行尾是否被Windows记事本的CRLF换行污染。用tr -d '\r'清理掉多余的回车符。

7.3 Host key verification failed：指纹变了跟我没关系？

现象：重装虚拟机或从快照恢复后，SSH连接弹红字“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”。这是正常的安全机制。因为客户端的known_hosts里保存了这台IP旧的公钥指纹，服务器指纹变了说明这台机器可能被替换，SSH因此拒绝连接。

知道原因就不慌。在宿主机上删掉旧指纹：

ssh-keygen -R 192.168.136.100

重新连接时，接受新指纹即可。不过要留意：如果你确实没有重装系统或修改密钥，指纹变化可能说明网络中有中间人，先确认虚拟机是谁再执行删除。

7.4 多个终端同时登录是否互相踢下线

常有人问，SSH登录后，另一个终端再登录同一台机器，会不会把前一个会话踢掉。默认情况不会。OpenSSH允许同一个账号建立多个并发会话，互不干扰，因为每个SSH连接时独立的sshd进程。除非有人手动配置了MaxSessions 1或在某些跳板机、堡垒机上做了单会话限制。如果遇到每次都强制下线的场景，去查一下sshd_config里是否有MaxSessions或MaxStartups限制，以及客户端是否配置了ControlMaster并错误共享了master连接。排查方法很简单：开着两个终端连接同一账号，如果两个都能正常操作，说明没被限制。

一些堡垒机系统会把同一个账号的多次登录合并成同一个会话，第二个设备接入时踢掉第一个，这是堡垒机的产品设计，不是SSH本身的行为。

7.5 虚拟机里出现图形界面黑屏怎么办

如果安装时选择带GUI，重启后卡在黑屏，但能听到启动音乐，可能是显示驱动问题。先切到文本终端，按Ctrl+Alt+F2，登录后安装驱动或禁用图形模式：

sudo systemctl isolate multi-user.target sudo dnf groupinstall "Server with GUI"

如果只是想维持命令行管理，黑屏黑到忍不了就直接用命令行模式，SSH连接根本不受图形界面影响。

7.6 初始指纹确认的陷阱

首次SSH连接输入yes回车，以后就正常。但有人输入yes时没看清系统提示，或者敲成了y，导致连接失败。正确操作是在提示后键入完整yes再回车。如果你用脚本批量执行SSH连接，需要在命令里加上-o StrictHostKeyChecking=accept-new来自动接受首次指纹，别用StrictHostKeyChecking=no这种关闭验证的写法，万一中间有伪服务器，那就等于把账号拱手相让了。

7.7 远程拷贝文件权限不对

用scp传文件到虚拟机后，文件属主和权限可能变成发起拷贝的用户或root。如果在SSH当前用户下不能写目录，会报Permission denied。先检查目标目录权限，必要时用chown和chmod调整。还有一个坑，传完文件后执行脚本提示/bin/bash^M: bad interpreter，这是Windows换行符问题。可以用sed -i 's/\r$//' script.sh修正。

关于这次部署过程，我的经验沉淀

整套流程走完以后，最深的体会是：SSH远程登录这件事，本质上是四层链路协作的结果——虚拟机网络通了、sshd服务起来了、防火墙放行了、客户端认证方式对了，这四个环节缺一不可。大多数“连不上”的问题最终都出在某一层配置上，而不是SSH本身出了问题。

最后贡献一个我自己的习惯：在RHEL9虚拟机交付前，我会在VMware里打一个干净系统的快照，命名为“base-installed”。之后每次改网络、改SSH配置前再快照一次。这个习惯救了我很多次，尤其是测试SELinux策略或防火墙规则时，一条命令写错，系统可能直接拒绝所有连接，连SSH都救不了自己，只能靠快照回滚。

如果你只是随便装来玩玩，那到这里你已经会了。如果你想在企业环境里复现这套方案，建议再往前走一步：把密钥认证、sshd_config加固参数、静态IP配置都写成Ansible剧本或脚本，这样以后每台新服务器都能在几分钟内完成同样标准的SSH部署，而不必每次都手工敲一遍。毕竟，手动操作这件事，第一次是学习，重复十次就是煎熬。