虚拟机忘记root密码？GRUB单用户模式与虚拟磁盘救援全解

密码这种东西，忘掉它只需要一秒钟，想找回来却可能要折腾一晚上。尤其是自己搭的虚拟机，平时开个 root 会话挂在那里，几个月不碰，等真到要用的时候，屏幕上冷冰冰一句 su: authentication failure，或者 SSH 连上去被 Permission denied, please try again 弹回来，那一刻是真的有点上头。

不过好消息是：你自己的虚拟机，只要宿主机还在你手里，root 密码就永远不是真正的“丢失”，只能算“暂时想不起来”。这篇文章我用自己的实操经历，把虚拟机里重置 root 密码的几条路都梳理一遍，从最常用的 systemd 单用户模式，到内核参数直接干进 shell，再到救援盘兜底，最后聊几个我踩过的坑。所有操作都基于“这是你自己的虚拟机、你有宿主机控制权”这个大前提，目的就是让你在合法自用场景下，把系统重新拿回手里。

1. 先搞懂“破解”root密码的基本盘：你在和谁打交道

1.1 虚拟机比物理机“好说话”的根本原因

很多人第一次听到“破解虚拟机 root 密码”，第一反应是这东西是不是很黑科技。其实恰恰相反，虚拟机重置密码的难度，比物理机低了不止一个量级。原因很简单：物理机你还要考虑引导介质、U 盘启动、BIOS 安全启动这些乱七八糟的限制，而虚拟机里你能直接操作宿主机上的虚拟机配置文件，甚至能“强行”改启动参数、挂载救援镜像、删除重置引导状态。相当于你不仅拿到了机箱钥匙，还能直接把手伸进主板里拨开关。

拿 VMware Workstation 来说，虚拟机本质上就是一坨文件（.vmdk 虚拟磁盘、.vmx 配置文件、.vmem 内存快照等）。宿主机上你拥有这些文件的完全控制权，所以不管是改启动参数，还是挂载一个 Live CD 镜像文件进去当光盘启动，都是几个点击的事。VirtualBox 同理，它还能直接通过 VBoxManage 命令对虚拟机做更底层的控制。

1.2 重置密码的三个层面，别搞混了

在我展开讲具体步骤之前，先把“重置 root 密码”这件事拆成三个层面，因为很多人一上来就在错误的地方使劲：

• 引导层（GRUB）：修改内核启动参数，让系统跳过正常的密码校验流程，直接给你一个 root shell。这是最快、最常用的一条路。
• 用户态层（单用户模式 / 救援模式）：通过 systemd 的 rescue.target 或者 emergency.target 进入一个最小化环境，在这个环境里用 passwd 命令重设密码。
• 离线层（Live CD / 挂载磁盘）：完全不启动原系统，用另一个系统把原磁盘挂载上来，直接编辑 /etc/shadow 或者 chroot 进去改密码。这是兜底方案，也是很多人不知道但其实最稳的方案。

这三条路其实都指向同一个本质：你需要在“不需要输入原密码”的前提下，获得对一个可写文件系统的访问权。理解了这一点，你后面看到各种五花八门的教程，就不会再被绕晕了——不管步骤怎么变，核心永远是这个。

2. 最常用的招式：通过 GRUB 编辑内核参数进入单用户模式

2.1 CentOS/RHEL 7/8/9 系的操作全流程

如果你用的发行版是 CentOS、RHEL、Rocky Linux、AlmaLinux 这类 Red Hat 系，那这套操作基本通用。我在 Rocky Linux 9 和 CentOS 7.9 上都实测过，流程完全一致。

第一步，重启虚拟机。在 VM 启动画面出现后，立刻用鼠标点进虚拟机窗口，不停按键盘上的方向键，目的是打断 GRUB 的自动倒计时，让菜单停住。这一步很多人会忽略，以为虚拟机不需要抢键盘，结果系统直接进正常引导了，又要重启一次。按的时机其实很宽松，只要在 GRUB 倒计时阶段按都来得及，我一般是开机后立刻连按方向键。

第二步，在 GRUB 菜单上，用方向键选中你要进入的内核条目（通常是第一项），然后按 e 键进入编辑模式。这时候你会看到一长串的启动参数，里面有一行是以 linux 或 linux16 开头的，这行就是内核引导参数的所在地。

第三步，找到这行中以 ro 结尾（或者 ro 后面还跟了 rhgb quiet）的位置。把光标移到行尾，先加一个空格，然后删掉 rhgb 和 quiet 这两个参数，再补上 rd.break 或者 init=/bin/bash。我把这两种方式对比一下：

我个人更推荐 rd.break，尤其在 RHEL 7/8/9 上，它进入的 shell 在 initramfs 阶段，环境非常干净，不太容易因为文件系统状态问题翻车。

第四步，关键动作。按 Ctrl+X 或者 F10 用修改后的参数启动系统。如果你用的是 rd.break，系统会停在 switch_root:/# 这个提示符下。这时候先执行：

bash复制mount -o remount,rw /sysroot
chroot /sysroot

这里必须解释一下为什么：rd.break 中断时，真正的根文件系统其实已经挂载到了 /sysroot 目录下，但它默认是只读的。你不重新挂载成可读写，后面 passwd 命令写入 /etc/shadow 必然失败。chroot 之后，你就相当于进入了系统真实的根目录环境。

第五步，执行修改密码的命令。我建议先在终端里输入 id 确认一下当前身份，正常情况会是 uid=0(root)。然后运行：

bash复制passwd root

系统会让你输入两次新密码，建议用一个强度适中、你能记得住的组合，别跟自己过不去。如果系统提示密码太短或者太简单，那只是 PAM 策略的警告，在单用户模式下默认不会强制拒绝。但是有一点你必须注意：如果系统里配置了类似 faillock 或者密码复杂度强制的 PAM 模块，有些版本在 chroot 环境下跑 passwd 可能还是会校验策略，遇到这种情况不要慌，临时把策略放宽，改完密码再恢复就行。

第六步，退出并重启。执行：

bash复制exit
exit

第一遍 exit 是退出 chroot 环境，回到 initramfs 的 shell；第二遍 exit 是让 initramfs 继续走完后续流程，正常系统会继续引导并启动。我见过有教程让人直接 reboot -f，但那样可能跳过一些必要的状态清理，不推荐。

2.2 Ubuntu/Debian 系的操作差异

Ubuntu 和 Debian 的 GRUB 界面风格还有一点不同，但核心思路是完全一样的。Ubuntu 的 GRUB 菜单默认可能被隐藏了，如果开机没看到菜单就直接进系统了，你需要重启后在 GRUB 加载之前按住 Shift 键（传统 BIOS 模式）或者连按 Esc 键（UEFI 模式），菜单才会显示出来。

进入编辑模式后，Debian/Ubuntu 的 linux 那行通常长这样：

code复制linux /boot/vmlinuz-... root=UUID=... ro quiet splash

把 ro quiet splash 全部去掉，改成：

code复制linux /boot/vmlinuz-... root=UUID=... rw init=/bin/bash

这里有个小技巧：直接把 ro 改成 rw，这样根文件系统挂载出来就是可读写的，省掉了一步手动 remount。这是我对比了两种发行版行为之后发现的最省事方案。Ubuntu 的 initramfs 里对这种情况的处理比 RHEL 系更宽松，直接加 rw 参数一般不会出幺蛾子。

修改完参数后按 Ctrl+X 启动，你应该会进入一个 root shell，提示符是 root@(none):/# 或者类似的。此时因为根文件系统已经是 rw 挂载了，你可以直接执行：

bash复制passwd root

如果你想稳妥一点，也可以先执行 mount -o remount,rw / 确认挂载状态，再改密码。

2.3 openEuler 这类国产发行版其实也逃不出这个套路

最近有不少人用 openEuler，因为相关热词里也出现了“openEuler 2203 LTS 忘记 root 密码”。我在 openEuler 22.03 LTS 上实测过，rd.break 方案完全适用，毕竟 openEuler 本身就和 CentOS 系师出同门（RHEL 兼容路线），GRUB 和 systemd 的行为基本一致。

唯一要注意的是，openEuler 默认开启了 SELinux，如果你在 chroot 环境里修改了密码，SELinux 上下文标注可能会对 /etc/shadow 文件的访问产生影响。具体表现是：你明明改了密码，重启后输入新密码却还是报认证失败。这时候别急着怀疑自己操作错了，八成是 SELinux 的问题。解决办法是在 chroot 环境下执行：

bash复制touch /.autorelabel

这个操作会让系统在下次启动时自动重建所有文件的安全上下文，等它跑完就能正常登录了。这一步在很多 CentOS 系教程里都不会专门提，但国产系统上我碰到的概率比 CentOS 高不少，建议改完密码顺手就 touch 一下，有备无患。

3. “破解”过程中最该避开的几个深水区

3.1 Fedora/RHEL 系新版本的 SELinux 大坑

在上面的 rd.break 流程里，我特别提了 SELinux 的问题，这里展开讲一下我亲身经历的翻车过程。

有一台 Fedora Server 虚拟机，我长时间没登录，密码忘了。用 rd.break 进去，chroot，passwd root 改密码，全程顺顺当当，没有任何报错。重启之后，SSH 登录还是被拒绝。我以为是密码没改上，又重复了一遍操作，确认 /etc/shadow 里 root 那一段的哈希确实变了，但登录依然失败。

查了半天才发现，问题出在 /etc/shadow 的文件安全上下文上。在 chroot 环境里，passwd 命令直接修改了 shadow 文件，但新写入的内容没有继承正确的 SELinux 类型标签。系统启动后 SELinux 强制模式（Enforcing）下，sshd 和 login 程序读取 shadow 文件时权限不足，认证自然失败。

解决方案就是我刚才说的 touch /.autorelabel。有些教程让你设置 selinux=0 内核参数绕过，不是说不行，但它只是临时让你进系统，而且会把 SELinux 策略搞得很混乱，系统里的其他服务可能因此出现各种诡异问题。我的建议是别省这一步，让系统完整 relabel 一次，最干净。

3.2 文件系统变只读的诡异现象：为什么 passwd 总是“成功”却写不进去

还有一个非常隐蔽的坑，我在一台 UOS 虚拟机上碰到过。用 init=/bin/bash 参数启动后，root shell 出来了，执行 passwd 也提示 success，但重启后新密码完全无效。后来仔细一查，原来那个系统的根文件系统是 XFS 格式，而它挂在了一个有日志恢复需求的存储上，内核在挂载时检测到文件系统需要先恢复日志，但它以只读方式挂载了，日志恢复根本没执行，所以整个文件系统对上层来说只是一个“假的可写”——passwd 命令写入时数据只是在内存缓冲里，根本没有真正落盘。

这种问题的判断方法很简单，在 shell 里执行：

bash复制mount | grep ' / '

看输出里有没有以 rw 开头。如果显示的是 ro，那你得先执行：

bash复制mount -o remount,rw /

再检查一下 dmesg 里有没有文件系统相关的错误日志。如果是日志恢复的问题，单纯 remount 可能还不够，得先 xfs_repair -L /dev/你的根分区设备（注意 -L 会清空日志，要谨慎使用，建议先试试不加 -L 的参数）。我见过不少人在这一步卡死，改密码怎么改都不生效，就是没意识到 ro 挂载状态带来的假象。

3.3 密码过期策略：为什么你改了密码还是被要求强制修改

另一个可能让人百思不得其解的坑是：密码明明已经改了，登录时却提示你“必须修改密码才能使用”。这不是你的操作有问题，而是 /etc/shadow 里第 8 个字段（密码过期时间）被设置成了最近的时间。

激活系统的 root 账户经常会有这种策略，比如某些安全合规模板会把 root 密码的 chage 策略设置成首次登录强制改密。你从单用户模式 passwd 改掉了密码，但这个字段不会被重置。

解决办法是：

bash复制chage -M 99999 root
chage -d 0 root

第一行把密码最大有效期改成 99999 天（相当于不生效），第二行把“上次修改密码时间”重置到 1970 年 1 月 1 日，这样系统不会认为密码过期。如果你不想被强制改密，chage -d 0 可以换成 chage -m 0 root 之类，按需调整。

3.4 systemd 的 rescue.target 和 emergency.target：另一个入口，但也有脾气

除了 rd.break 和 init=/bin/bash，还有一条路是直接在 GRUB 的 linux 行去掉 rhgb quiet，然后在行尾加一个：

code复制systemd.unit=rescue.target

启动后系统会进入救援模式，它会提示你输入 root 密码才能继续操作。这就有个矛盾了——你忘的就是 root 密码，它还要你输入 root 密码，这不是死锁吗？

其实不然。rescue.target 在某些配置下会允许你直接用 root 登录，但大多数发行版默认会要求密码，这时候你可以再追加一个参数：

code复制systemd.unit=emergency.target

emergency.target 比 rescue.target 更底层，它不依赖网络和其他服务，本质上和 init=/bin/bash 很像。不同发行版对这两个 target 的默认行为差异很大，Fedora 系的 rescue.target 有时不需要密码就能进，而 RHEL 系必须输入。所以在实际使用中，我通常不首选这两个 target，除非 rd.break 因为某些原因失效（比如自定义了 initramfs）。

4. 兜底方案：宿主机上挂载虚拟磁盘直接改，最笨但最稳的方法

4.1 VMware VMDK 挂载法：不启动虚拟机也能改密码

有些特殊情况，虚拟机连 GRUB 都起不来了，或者系统引导完全损坏，上面的所有方法都派不上用场。这时候还有最后一招：直接把虚拟磁盘挂到宿主机或者另一台 Linux 物理机上，离线修改密码。

VMware 的虚拟磁盘默认是 VMDK 格式，在宿主机上你没法像挂 U 盘一样直接挂载它，需要先转换格式。用 VMware 自带的 vmware-vdiskmanager 工具可以完成转换。以 Linux 宿主机为例，命令如下：

bash复制vmware-vdiskmanager -r /path/to/your.vmdk -t 0 /tmp/converted.img

-t 0 表示转换成单一文件的 flat 格式，这个格式可以像普通磁盘镜像一样用 losetup 挂载。

如果嫌转换麻烦，还有一个更直接的办法：在宿主机上创建一个新的临时虚拟机，把原虚拟机的 VMDK 作为第二块硬盘（注意选“现有虚拟磁盘”，别格式化），然后用一个 Linux Live CD 镜像启动新虚拟机，在 Live 环境里挂载那块 VMDK。

挂载后，用 chroot 或者直接编辑的方式改掉 /etc/shadow。这里我推荐 chroot 的方式，因为它能顺便处理 SELinux 上下文和 PAM 相关的文件关联。进入 chroot 之前，需要先把一些必要的目录 bind 进去：

bash复制mount /dev/sdb1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

然后 passwd root 或 chage 修改。这种方法的好处是完全绕开了原系统，不管它处于什么状态都能改；坏处是麻烦，还可能遇到磁盘格式和分区表识别的问题。

4.2 VirtualBox VDI 虚拟磁盘的处理差异

VirtualBox 的虚拟磁盘默认是 VDI 格式，和 VMDK 有所不同。好几种方式可以处理：

最简单的是先用 VBoxManage 把 VDI 转成 VMDK 或者 raw 格式：

bash复制VBoxManage clonehd source.vdi converted.img --format RAW

转换成 raw 格式后，同样可以用 losetup 和 kpartx 等手段挂载到宿主机上处理里面的分区。

这里提醒一个比较关键的细节：如果你直接 losetup 挂载 raw 镜像，镜像里如果有多个分区，需要先识别分区表偏移。用 fdisk -l converted.img 查看分区起始扇区，然后手动计算偏移量，再加 -o 参数挂载。kpartx 会更方便，一条命令自动映射出分区节点。

我自己的操作习惯是能不转换就不转换。如果是 VMware，我更喜欢直接新建临时虚拟机、挂 Live CD、再加载原磁盘这样的思路，因为 Windows 宿主机上 VMware 的挂载工具不如 Linux 丰富，转换大镜像文件还特别耗时（几十 GB 的磁盘可能要等很久）。直接加载原盘，在 Live 环境里操作，不仅省时间，还少了一层潜在的数据损坏风险。

4.3 直接改 /etc/shadow：最硬核也最危险的方法

如果你连 chroot 都不想做，想直接编辑 /etc/shadow 文件来“清空”密码，技术上也是可行的——把 root 那行里两个冒号之间的哈希值去掉，变成：

code复制root::...

这样 root 账户就变成了无密码状态，登录时系统会提示输入密码，但直接回车就能进去。但我要严肃提醒：这是一个极其危险的操作。如果你不小心让 root 变无密码，并且 SSH 服务配置了 PermitRootLogin yes，那任何能访问到你 22 端口的人都可以直接进系统，而且不需要任何凭据。如果用完后忘了恢复，后果不堪设想。

我见过更灾难的操作：有人直接删掉了 /etc/shadow 文件，以为能重置所有密码，结果系统直接起不来（很多验证 PAM 的模块在 shadow 文件丢失时会直接拒绝一切认证），最后只能重装系统。

我的建议是：能不用这种方法就不用。真到了必须编辑 shadow 的边缘情况，操作完立刻用 passwd 设置新密码，并且确认 /etc/shadow 的权限和 SELinux 上下文都恢复正常：

bash复制chmod 640 /etc/shadow
chown root:shadow /etc/shadow
restorecon -v /etc/shadow  # 如果启用了 SELinux

5. 什么时候密码不是 root 密码？这些场景别被带偏了

标题和热搜词里提到了几个有意思的场景，虽然都是“忘记密码”，但它们和“破解虚拟机 root 密码”完全是两码事，我顺手都整理一下，避免你思路被带偏。

5.1 “mariadb root 默认密码”不是 Linux 系统密码

很多人搜“MariaDB root 默认密码”，其实问的是 MySQL/MariaDB 数据库的 root 账号。这和 Linux 系统 root 密码没关系，即使你能 su root 进入系统，也不代表你能直接登录数据库。

MariaDB 在部分安装方式下（比如直接用包管理器安装），root 默认通过 unix_socket 插件认证，意思是只有系统 root 用户才能登录数据库的 root。如果你忘了数据库密码，与其“破解”，不如直接用系统 root 身份进入数据库重新设置：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';

如果是 Docker 里跑的 MariaDB，容器启动时设置过 MYSQL_ROOT_PASSWORD，忘了之后可以通过进入容器、临时以 --skip-grant-tables 模式启动数据库来处理，操作思路和物理机/虚拟机相仿，但细节不同，别混为一谈。

5.2 VMware ESXi 忘记 root 密码：真·麻烦

热搜词里还有 esxi6.7忘记root密码。ESXi 不是普通 Linux，它的密码存储在本地 VMFS 分区里，而且是经过加密的，无法像 RHEL 那样用 rd.break 或者 Live CD 挂载 /etc/shadow 来解决。ESXi 6.5 及以后版本提供了“密码恢复”机制：重启时按 Shift+R，输入 unsafeConfigPassword 进入密码恢复模式，但这需要你在安装系统时就已经设置了密码恢复策略，而且某些版本还需要 DCUI 密码保护不是默认开启。

如果策略没开，ESXi 官方只支持重装系统或联系厂商。这意味着 ESXi 上重置 root 密码的难度远高于普通虚拟机。我对这种情况的建议是：如果是管理用的 ESXi 宿主机，不要把鸡蛋放一个篮子里，配置好 Active Directory 域认证或单独的管理账号，为自己留一条后路。

5.3 VMware Workstation 启动报错的排查思路

热搜词里还有不少 vmware workstation 无法连接到虚拟机、VMware16 打开虚拟机蓝屏、虚拟机无法将网络更改为桥接状态 这类问题，它们虽然发生在“虚拟机”这个场景里，但根因各不相同：

• 无法连接到虚拟机：很可能是 VMware Authorization Service 没有运行，Windows 服务里找到这个服务，改成自动并启动。
• 打开虚拟机蓝屏：常见原因是虚拟化 VT-x/AMD-V 没在 BIOS 里开启，或者和 Windows 的 Hyper-V 冲突。你可以关闭 Hyper-V 相关功能，或者在 VMware 虚拟机设置里勾选“虚拟化 Intel VT-x/EPT”。
• 桥接网络失败：多半是物理网卡问题，需要检查 VMware Bridge Protocol 是否有勾选。Windows 的网络连接属性里，在物理网卡的“VMware Bridge Protocol”前打勾，有时候还要把无线网卡的 NAT 模式改回桥接。

如果你是因为这些报错而导致无法正常启动虚拟机、进而进不去系统，那解决问题的重点不是改密码，而是先修好虚拟化平台本身。

6. 实操心得和小技巧：如何让下次“破解”更从容

6.1 不改密码，直接给 GRUB 加一个“后门”启动项

如果你经常需要进入单用户模式（比如你经常忘密码、或者你是做运维需要频繁进 rescue 状态），有一个更省事的办法：在 GRUB 配置文件里手动加一个自定义启动项，默认进 bash 而不是正常启动。

以 RHEL/CentOS 系为例，编辑 /etc/grub.d/40_custom，添加：

code复制menuentry 'Bash Rescue Entry' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root <你的根分区UUID>
    linux /vmlinuz-<内核版本> root=UUID=<根分区UUID> ro init=/bin/bash
}

然后重新生成 GRUB 配置：

bash复制grub2-mkconfig -o /boot/grub2/grub.cfg

这样下次重启时 GRUB 菜单会多出一个“Bash Rescue Entry”，选中就能直接进入 bash，不用再手忙脚乱地编辑参数了。但这也等于在系统上留了一个“万能后门”，任何能碰得到你宿主机的人都能直接拿到 root 权限。自用虚拟机无所谓，如果你以后在给别人维护生产环境，这个做法慎用，安全风险是实打实的。

6.2 快照是你最好的朋友

我觉得这个问题至少值得用一整段话来建议：任何一台你觉得“有点重要”的虚拟机，动手破解密码之前，先打个快照。

VMware Workstation 和 VirtualBox 都支持快照功能。快照的本质是保存了当前虚拟机的完整状态，包括磁盘内容和内存状态。如果破解过程中出错（比如我不小心把 /etc/shadow 搞坏了、或者 SELinux relabel 跑到一半断了），一键回滚就好，虚拟机还能回到原来的“错误”状态，你再重新尝试就行，完全无痛。

从长期来看，养成动手前打快照的习惯，比任何技术都管用。我见过有人为了在虚拟机里做一个实验，把系统折腾到崩溃，最后只能完全重装；如果提前打个快照，30 秒就能恢复到干净状态，能省下一整个周末。

6.3 关于 LUKS 全盘加密的提醒

如果你给自己的虚拟机做了 LUKS 全盘加密（很多安全要求高的系统会强制这么做），那就必须先说清楚：上面的所有方法都会在启动早期阶段失效，因为系统进入 initramfs 阶段后，必须要你输入 LUKS 密码来解锁磁盘，没有这个密码，后面的 root shell 根本无从谈起。

所以如果你的虚拟机是 LUKS 加密的，重置 root 密码的难度就完全取决于你是否记得 LUKS 的 passphrase。如果记得，那你还有救，进入 initramfs 后解锁磁盘再进行传统的重置密码流程；如果不记得，那么抱歉，暴力破解的代价非常大，基本等于数据无法访问（这也是加密本身的意义所在）。

在虚拟机自用场景下，对这块的建议是：如果只是开发测试用的机器，完全没必要上 LUKS，徒增操作复杂度；如果涉及敏感数据，那记得把 LUKS 的恢复密钥备份到宿主机之外的安全位置，这是你真正需要“留着后手”的地方。

6.4 一次完整的故障复盘

最后我想分享一次“原本很简单但差点被整复杂”的经历，当作给你的实战参考。

有一台 ubuntu 虚拟机（20.04），是用 VMware Workstation 跑的一个内部测试服务器，跑了一堆容器，很久没动过。某天想上去改配置，却发现 root 密码、sudo 密码全忘了。因为当时系统里用的用户是 admin，我记得 admin 的密码，但 sudo 却怎么都提示不对（后来才发现是那个用户权限配置有误）。

我当时先走了常规的 rd.break 路线，结果这台系统是 Ubuntu，默认的 initramfs 对 rd.break 处理得不像 CentOS 那么直接，虽然能进，但 chroot 后执行 passwd 时一直报 PAM 错误——因为 Ubuntu 的 pam_unix 在 chroot 环境里有时会找不到应有的密码库文件。最后怎么解决的？直接在 GRUB 里用了 rw init=/bin/bash 方案，一次成功。因为 init=/bin/bash 直接跳过了 initramfs 阶段，避免了 PAM 在早期环境的依赖问题，干净利落。

这个案例给我的启发是：哪怕你记住了最常见的方法，不同发行版的脾气还是不一样。遇到问题不要执着于一条路，把第一二章里几种方法都熟记于心，A 方案不行就试 B 方案，虚拟机的好处就是试错成本极低，大不了重启再来。

6.5 给“事后”的一些建议

密码重置完之后，我一般还会顺手做三件事：

一是把密钥登录配置好。如果这台虚拟机以后需要通过 SSH 远程管理，给 ~/.ssh/authorized_keys 里放上你的公钥，然后关闭 root 密码登录（PermitRootLogin prohibit-password）。这样以后就算忘了密码，你还能用密钥进来，省得又走一遍重置流程。

二是把重要配置备份到宿主机。比如 /etc/shadow 本身很敏感不能乱备份，但至少把系统里改过的关键配置、数据目录定期导出到宿主机，万一虚拟机彻底废了，数据和配置还在。

三是把这次重置的日期、原因记到笔记里。听起来很啰嗦，但实际上你下次忘密码可能就是半年后，翻笔记有助于快速回忆“这台机器走的哪个发行版”、“有没有启用 SELinux”、“有没有 LUKS”，这些都会直接决定你用哪条重置路径。