Linux忘记root密码怎么办？四种重置方案与原理全解析

先给你讲个场景：手头一台跑了三年很少登录的服务器，某天报警说磁盘满了，你想上去处理，结果发现 root 密码早被记在一张找不见的便利贴上。这种“救急”时刻在 Linux 运维里太常见了，越是不常动的机器，越容易在关键时刻给你来这么一下。重置 root 密码并不是什么高深技术，但属于典型的“平时用不上、用时必须会”的生存技能。

这篇内容我会围绕 Linux 忘记 root 密码后的完整处理思路展开，覆盖企业 Linux 发行版（RHEL/CentOS 系）和 Ubuntu/Debian 系，也会讲救援模式与 Live 系统的方法。整篇不只给命令，还会解释每一步背后的原理，以及我在实际环境中踩过的坑。适合刚接触服务器运维的新手，也适合长期远程办公、手边没有完整文档的管理员参考。

1. 项目概述：root 密码遗忘之后，接下来怎么办

1.1 哪些场景会触发“重置 root 密码”需求

很多人以为忘记 root 密码是新手才会犯的低级错误，其实越是在生产环境待得久，越容易遇到。最容易触发这个需求的有几类情况。

第一类是交接问题。团队里负责某台机器的人离职了，密码只存在于文档或者某个人的脑瓜里，其他人完全没有记录。很多内部服务器的密码可能三年五年都没人动过，等到要改配置才发现谁也登录不进去。

第二类是密码过期与策略调整。某些等保要求较高的环境会配置密码定期过期策略，如果某台机器长期无人登录，密码到期后自动失效，你用旧密码登录会被直接拒绝。虽然在有网络和正常认证的情况下可以走密码找回流程，但如果同时把密码忘记了，就只能通过物理控制台方式处理。

第三类是公钥登录久了，root 密码从未被记录。不少运维习惯只配置 SSH 密钥登录，root 密码从装机之后就没再使用过，真要哪一天密钥文件损坏、或者需要从带外管理口登录，就发现 root 密码完全想不起来。

第四类是账户被误操作锁定。比如有人执行了passwd -l root或者usermod -L root，把 root 账户锁住，之后所有人都在猜为什么密码正确却登录不进去。

这类问题“急”就急在生产环境不能长时间停机，又必须在有限的维护窗口内完成。所以掌握一两条稳定的重置路径，比临时翻手册要可靠得多。

1.2 动手之前，先确认环境的三个问题

在重启机器之前，我强烈建议先花两分钟确认三个基础信息，否则可能把原本的小事搞成大事故。

第一个问题：这台机器能不能重启？如果它上面跑着数据库主节点、正在执行批量任务、或者有未完成的事务，直接重启可能会造成数据不一致。要先把服务切换到备机，或者明确这只是测试环境、可以随时中断。重置 root 密码的大多数方案都需要重启系统，所以这个前提必须确认清楚。

第二个问题：根分区是否加密？如果你的服务器启用了 LUKS 全盘加密，那么进入救援模式后还需要输入加密密码或者加载密钥文件才能看到文件系统。如果不确定，先检查一下启动时有没有输入密码的步骤。有加密的机器，重置思路会稍微复杂一点，但命令本身没有区别。

第三个问题：有没有可用的带外管理通道？物理服务器通常有 IPMI 或带外管理卡，虚拟机一般有厂商提供的控制台。因为整个操作过程基本都在字符界面完成，你需要确保能通过某种方式看到 GRUB 菜单和系统输出。远程 SSH 是无法完成这个操作的。

我还遇到过一种情况：机器是虚拟机，但虚拟化平台本身能提供“重置密码”按钮。如果生产环境确实不允许停机重启，优先考虑云厂商或虚拟化平台提供的官方重置入口，这是影响最小、也最合规的方式。手动方式更多用于本地物理机、私有环境或平台没有重置功能的场景。

环境确认完成后，下面的思路才是通用的：通过控制台进入一个避开正常认证流程的 root shell，重新设置密码，然后修复可能影响登录的额外问题。

2. 核心原理解析：先搞懂这三个机制再动手

2.1 引导流程中，哪里才是“动手的机会”

一套 Linux 系统从按下电源到出现登录提示，大概要经过这样几个阶段：固件（BIOS/UEFI）加载引导程序，GRUB 2 接管并显示启动菜单，然后内核被加载，随后 initramfs 把必要的驱动和初始文件系统准备好，再交给 systemd 启动各项服务，最后才进入登录认证窗口。

重置 root 密码的关键窗口，就藏在 GRUB 菜单停留的时候。GRUB 2 在默认配置下会在启动菜单前停留几秒，并且允许我们按 e 进入当前启动项的编辑界面。通过修改内核启动参数，可以让系统跳到一个“不加载完整服务、不需要登录密码”的环境里。

这里有一个很核心的认知：重置 root 密码并不是系统漏洞，而是把“物理接触或控制台访问”视为最高权限的设计理念。能亲手在键盘上按出 GRUB 编辑菜单的人，已经等价于拥有了控制台操作权。所以生产服务器通常要配合 LUKS 加密、固件密码和带外管理口安全策略来做纵深防御。

只要你想明白了这一点，后面所有方案的核心都是同一个目标：在系统进入完整多用户环境之前，拿到一个拥有 root 权限的 shell，并且让根文件系统处于可写状态。目标明确了，面对任何没见过的新发行版，也能自己推导出合适的操作。

2.2 init、systemd 目标与内核参数

早期 SysV init 时代，重置密码通常是往内核参数里追加一个single或者s，系统启动后直接进入单用户模式，不需要输入密码就能获得 root shell。这个做法简单粗暴，在很多老文档里你还能看到。

到了 systemd 时代，单用户模式被拆分成了 rescue.target 和 emergency.target。比较有意思的是，RHEL 7 及以后的版本在默认配置下，单纯进入 rescue.target 仍然会要求你输入 root 密码。这就尴尬了，本来就是因为忘密码才进来，结果还要密码。所以不同发行版演化出了不同的绕过方式。

我整理了四个常见“入口”，用途稍有差异：

rd.break是这几年来 RHEL 系环境里最常用的方案。它会在加载 initramfs 后、真正切到系统根文件系统之前停下来，给你一个switch_root:/#提示符。这时候系统根目录已经挂载在/sysroot下，你只需要把它重新挂载为可写，再 chroot 进去就能修改密码。

init=/bin/bash则更通用一些，原理是让内核启动后直接执行 bash 而不是 systemd。好处是几乎所有 Linux 发行版都支持，坏处是它绕过了正常的系统初始化流程，你可能需要手动处理根文件系统挂载状态。

2.3 密码存储、账户锁定与 PAM/SELinux

很多新手以为重置密码就是改/etc/shadow文件里的字符串，实际操作中通常会遇到三个额外障碍：PAM 密码策略、账户锁定标记、SELinux 上下文。

先讲密码存储。加密后的密码字段在/etc/shadow文件中，root 用户那一行用冒号分隔，第二列就是密码散列。不同发行版可能使用 SHA-512、bcrypt 或 yescrypt 等不同算法，格式上通常是$6$salt$hash这类。正常情况下我们不需要手工编辑这个字段，直接用passwd命令由系统生成散列并写回 shadow，既安全又省事。

然后是 PAM。passwd命令会调用系统安全模块做密码复杂度检查。如果你的环境配置了pam_pwquality，要求密码至少 12 位且包含大小写、数字、特殊符号，而你顺手输了一个123456，passwd 会直接拒绝。有些加固系统还配置了失败锁定，如果你在救援环境中反复输错密码，可能会触发pam_faillock锁定。这时候光改密码还不行，可能还需要清理失败计数。

再讲账户锁定标记。如果 root 账户被usermod -L或passwd -l锁定过，/etc/shadow中密码字段前面会带上!或!!前缀。单纯执行passwd root在大多数发行版上会清除锁定标记，但并不是所有发行版都这么智能。如果你重置完密码后仍无法登录，先在 shadow 里检查一下密码字段是不是还有感叹号，必要时执行passwd -u root解锁。

最后是 SELinux，这一块最容易被忽略。RHEL/CentOS 系默认开启 SELinux，文件都有安全上下文标签。我们在 chroot 环境或者 initramfs 阶段直接改写/etc/shadow，可能会让新文件被打上错误的上下文标签。重启后 SSH 或 login 进程读取 shadow 时会被 SELinux 拒绝，表现为“密码老是提示错误，实际上密码完全没问题”。解决办法是执行touch /.autorelabel让系统在下一次启动时重新标记所有文件，或者通过restorecon -v /etc/shadow单独修复这一个文件的上下文。

3. 实战方案一：企业 Linux 发行版（RHEL/CentOS 系）重设 root 密码

3.1 最推荐的方式：rd.break

这个方法在 RHEL 7、RHEL 8、RHEL 9 以及对应衍生发行版上都验证过可用，也是 Red Hat 官方文档推荐的思路。

操作步骤非常稳定，我按顺序拆开讲。

第一步，重启服务器，当 GRUB 菜单出现时，在默认启动项上按 e 进入编辑模式。注意不是按回车直接启动，而是按字母 e。

第二步，找到以linux开头的那一行。不同版本可能显示为linux或linux16，这行内容比较长，包含内核镜像路径、根分区参数、以及各种启动参数。把行尾的ro改成rw，然后在行尾追加一个空格和rd.break。

修改前可能长这样：

linux16 /vmlinuz-5.14.0-362.el9.x86_64 root=/dev/mapper/rl-root ro crashkernel=auto ...

修改后变成：

linux16 /vmlinuz-5.14.0-362.el9.x86_64 root=/dev/mapper/rl-root rw crashkernel=auto ... rd.break

这里有一个关键点：ro改成rw的目的是让根文件系统在后续挂载时以可写方式挂载，否则你进入环境后还要手动处理只读问题。rd.break会让 initramfs 在它自己的阶段停下来，而不是直接切到真正的系统根目录。

第三步，按 Ctrl+X 启动。你会看到系统停在switch_root:/#提示符。

第四步，此时系统根目录已经挂载在/sysroot下，但往往还是以只读方式挂载。先手动让它可写，然后 chroot 进去：

mount -o remount,rw /sysroot chroot /sysroot

第五步，执行passwd root，输入两次新密码。如果系统有密码复杂度策略，你需要按策略要求输入足够强度的密码。

第六步，这一步非常关键。如果系统启用了 SELinux 且处于 enforcing 状态，执行：

touch /.autorelabel

注意，这一步是在 chroot 后的根目录下执行，也就是说实际创建的是/sysroot/.autorelabel文件。这个文件会告诉系统下一次启动时重新标记所有文件的 SELinux 上下文。系统重启后会有一段明显的延迟，那是它在逐文件重打标签，属于正常现象。

第七步，连续输入两次exit，退出 chroot 并继续启动，也可以直接执行reboot。建议先exit两次让系统走正常流程，避免强制重启导致其他问题。

为什么我不建议直接用single模式来替代？因为在 RHEL 系较新版本上，进入单用户环境仍然可能要求 root 密码。rd.break 是在 systemd 接管之前就停住，完全不需要密码，因此更可靠。

3.2 备用方式：init=/bin/bash

如果某种特殊原因导致 rd.break 不生效，或者你想验证其他通用方法，可以用init=/bin/bash。

步骤开头和之前一样，到第二步时，将ro改成rw，然后在行尾追加init=/bin/bash。例如：

linux16 /vmlinuz-5.14.0-362.el9.x86_64 root=/dev/mapper/rl-root ro crashkernel=auto ...

改为：

linux16 /vmlinuz-5.14.0-362.el9.x86_64 root=/dev/mapper/rl-root rw crashkernel=auto ... init=/bin/bash

按 Ctrl+X 启动后，系统会跳过 systemd，直接运行 bash，提示符变成bash:/#或#。此时没有网络、没有各种服务，这就是预期状态。

在这个 shell 里，你先确认根目录是否可写。如果只读，执行：

mount -o remount,rw /

然后直接passwd root重置密码。完成后，如果系统有 SELinux，同样执行：

touch /.autorelabel

最后，建议执行exec /sbin/init让系统继续完成正常启动流程，或者直接reboot -f。注意这里因为有 bash 作为 PID 1，直接 reboot 也可以，但走一下 exec init 会让系统关闭流程更干净。

这个方式的优点是通用，几乎任何发行版都能用；缺点是它跳过了 fstab 处理、设备挂载、服务启动等流程，如果根分区依赖特殊驱动或者 LVM 卷组没有激活，可能会遇到挂载问题。所以在 RHEL/CentOS 系上，我优先推荐 rd.break。

3.3 一个容易误解的点：为什么“能改密码”不等于“系统被入侵”

以前总有人问：如果谁能物理接触服务器就能改 root 密码，那系统安全从何谈起？

其实这类重置方式的本质，是把引导加载程序层面的“控制台访问权”视为最高权限。只要攻击者能接触到键盘和显示器，他确实可以通过重置密码拿到系统访问权，这是设计上的取舍。真正可靠的防护是下面这几层：

• 对根分区启用 LUKS 全盘加密。没有加密密钥，攻击者用救援模式挂载分区时看到的只是乱码数据。
• 在固件层设置 BIOS/UEFI 密码，阻止他人任意修改启动顺序和引导参数。
• 把 IPMI、带外管理口放在独立管理网络中，限制物理可达范围。

生产服务器如果能做到全盘加密，即使有人拿到了控制台，也无法轻易重置 root 密码。这个话题经常会被放到安全审计中讨论，所以我特意说明一下：重置密码只是一种运维自救手段，不是绕过安全边界的漏洞。

4. 实战方案二：Ubuntu/Debian 系重设 root 密码

4.1 调整 GRUB 内核参数，进入 root shell

Ubuntu 和 Debian 系的处理思路与 RHEL 系类似，但有一些发行版特有的差异。

第一步，重启系统。如果 GRUB 菜单一闪而过，可以连续按 Esc 或 Shift 键把它调出来。Ubuntu 默认可能隐藏菜单，按键时机需要多试几次。

第二步，在菜单上选中当前使用的内核那一项，按 e 进入编辑模式。

第三步，找到以linux开头的那一行，把ro改成rw，并在行尾追加init=/bin/bash。

修改前类似：

linux /boot/vmlinuz-5.15.0-91-generic root=UUID=xxxx ro quiet splash

修改后：

linux /boot/vmlinuz-5.15.0-91-generic root=UUID=xxxx rw quiet splash init=/bin/bash

第四步，按 Ctrl+X 或 F10 启动。不同版本的 GRUB 按键略有差异，通常屏幕下方会有提示。

第五步，系统会直接进入 root shell。执行：

passwd root

这里要说明一个常见误解。Ubuntu 服务器版默认 root 用户没有可用密码，你日常用的账户是通过 sudo 提权来管理的。如果你只是忘记了普通用户密码，在这个 shell 里执行passwd 你的用户名同样可以重置。如果你希望同时设置 root 密码，就执行passwd root。

第六步，完成后执行reboot -f，或者先exec /sbin/init再正常重启。

这个方法在 Debian、Ubuntu Server、以及它们的衍生发行版上都很通用。需要注意的一点是，如果你把/etc/shadow中 root 原本无密码的状态改成了有密码，系统后续行为会变成 root 可以直连 SSH。如果这不是你想要的安全状态，重置完普通用户密码后，可以把 root 密码用passwd -dl root再次锁定。

4.2 使用 recovery mode

如果你不想手动编辑内核参数，Ubuntu 还提供了一个更温和的入口：recovery mode。

重启后进入 GRUB 菜单，选择“Advanced options for Ubuntu”，你会看到每个内核版本都有一个带了(recovery mode)后缀的条目。选择它进入。

接下来会出现一个简易菜单，里面有 fsck、network、root 等几个选项。我们选“root - Drop to root shell prompt”，就能进入 root shell。

这个 shell 里的根文件系统有时是只读的，尤其是你在恢复模式下选择了 fsck 之后。所以先执行：

mount -o remount,rw / passwd root

注意，recovery mode 本质上不是绕过认证，而是提供一个不需要输入密码的维护环境。和改内核参数相比，它对小白更友好，因为不需要自己去改 GRUB 原始行，降低了误操作的风险。

4.3 关于 sudo 权限和失败锁定的补充

在 Debian/Ubuntu 系里，重置完密码之后还可能出现一个“隐藏坑”：如果你前面用 PAM 配置了失败锁定策略，登录时连续输错几次密码，账户会被锁定一段时间。这个时候即使密码已经重置正确，系统依然会拒绝登录。解决方法是回到 root shell 里执行：

faillock --user root --reset

或者在确认禁用pam_faillock的情况下直接清空相关状态文件。如果没有配置失败锁定策略，可以忽略这一点。我在实际环境里见过不少因为反复试密码导致锁定的情况，重置密码前先检查一下系统里有没有pam_faillock.so相关配置，能省很多时间。

5. 实战方案三：救援模式 / Live ISO 重置密码

5.1 什么时候必须用救援介质

如果你遇到的不是单纯的忘记密码，而是 GRUB 菜单根本进不去、引导配置损坏、内核 panic、或者系统完全无法进入单用户模式，那前面两种方案都走不通。这时候唯一可行的路径，就是用安装光盘或者 Live USB 启动到临时环境，再挂载系统盘来重置密码。

另外，如果机器是加密根分区，但你在引导阶段输入加密密码后仍然卡住，也需要借助安装介质来排查。

5.2 安装介质启动后的完整手动挂载流程

以某个主流发行版的安装 ISO 为例，启动后通常会提供“Troubleshooting / 救援模式”或者“Try / 试用”入口。无论选哪个，最终都能得到一个可操作的 shell。

进入 Live 环境后，按下面的顺序操作。

第一步，查看系统的分区结构。用lsblk -f查看设备挂载关系，同时确认文件系统类型和挂载点。如果系统使用了 LVM，则再用pvs和lvs查看卷组和逻辑卷。

lsblk -f

第二步，激活 LVM 卷组。如果你看到根分区位于/dev/mapper/xxx-root，说明系统使用了 LVM，需要先激活卷组：

vgchange -ay

如果你是 LUKS 加密分区，还需要先用cryptsetup打开加密设备：

cryptsetup luksOpen /dev/sda5 cryptroot

之后出现/dev/mapper/cryptroot，再把这个设备挂载到准备目录。这一步经常被忽略，表现为救援模式下找不到根文件系统，其实是加密层没有先解锁。

第三步，创建挂载目录并挂载根分区。假设根逻辑卷是/dev/mapper/vg0-root：

mkdir -p /mnt/sysroot mount /dev/mapper/vg0-root /mnt/sysroot

如果/boot是独立分区，也要挂载：

mount /dev/sda1 /mnt/sysroot/boot

第四步，绑定挂载虚拟文件系统。这一步不是为了“看起来完整”，而是为了让 chroot 环境里的工具能正常工作：

mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys

第五步，chroot 到系统根目录：

chroot /mnt/sysroot /bin/bash

第六步，重置密码：

passwd root

第七步，如果系统使用 SELinux，根据需要执行：

touch /.autorelabel

或者只修复 shadow 文件的上下文：

restorecon -v /etc/shadow

第八步，退出 chroot 并重启：

exit reboot

完成之后，拔掉安装介质，让服务器正常从硬盘启动。

5.3 为什么不 bind /dev /proc /sys 就会出问题

很多教程会在 chroot 相关步骤时写“挂载 /dev、/proc、/sys”，但很少解释为什么。我实际遇到过不挂载就执行 passwd 失败的情况，所以特意讲一下。

chroot 只是把根目录切换到你指定的目录，但进程内核对系统的感知没有改变。像/proc是内核暴露运行时状态的虚拟文件系统，许多命令会读取它来判断系统信息；/sys则提供设备、驱动、内核参数等信息；/dev对应设备节点，passwd生成随机盐时会访问/dev/urandom，如果没有对应的设备节点，可能直接报错或者长时间卡住。

不挂载这三个目录，你在 chroot 环境里执行命令时会有种“系统半身不遂”的感觉：有的工具能跑，有的工具报一堆奇奇怪怪的错误。所以 rescue 环境下，一定养成先 bind 再 chroot 的习惯。

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

6.1 问题现象与解决方案速查

我在实际操作中见过不少朋友卡在看起来很小的细节上，下面整理成一张速查表，方便你现场对照。

6.2 实际操作中的三个高频失误

第一个高频失误是改内核参数时改错了行。GRUB 编辑界面里通常有两三行内容，包括linux开头和initrd开头的行。你只需要修改linux开头那一行，不要动initrd那行。改错了可能会让内核找不到初始文件系统，系统直接启动失败。

第二个高频失误是忘了记录原始行内容。编辑 GRUB 时是按内存中的临时配置启动，不会永久写入磁盘，所以理论上改错了重启一次就恢复。但如果你把ro改成rw后又在行尾追加了参数，却记不清原来那行的完整内容，排查起来就会很吃力。我的习惯是在按 e 之前先拍照或者截屏保存原始行，这样一旦改坏，能原样还原。

第三个高频失误是忽略 SELinux autorelabel 流程。执行完touch /.autorelabel之后，系统重启时确实会自动重打标记，但如果你的机器配置文件非常多，这个过程可能持续十几分钟甚至更久。有些朋友看到启动界面长时间不动，以为卡死了，就直接强制关机，结果中断了标记流程，下一次启动反而更糟。遇到这个场景，多等几分钟，观察磁盘是否还在持续读写。

6.3 应对“密码策略 / 等保加固”环境的经验

如果你所在的团队环境配置了严格的 PAM 密码策略，那么即使你顺利进入了 rescue shell，执行passwd时仍可能被策略拦截。每次碰到这种情况，我的经验是不要急着去改 PAM 配置文件，先想清楚这次重置的合规影响。

比较稳妥的流程是这样的：先按照系统策略设置一个足够复杂的临时强密码，成功进入系统后用合法渠道修改密码策略或者申请正式密码。如果实在需要临时绕过策略，可以备份并修改/etc/pam.d/system-auth或/etc/pam.d/common-password中pam_pwquality.so那一行，重置完密码后立刻恢复原文件。

这种操作涉及合规状态，不建议在审计严格的环境里擅自改动。最安全的方式永远是“先满足策略，再谈其他”。还有一个容易被忽略的点：如果你重置了密码，但系统设置了密码过期时间，下一次登录时可能仍然会强制你改密码。这其实是正常流程，不是问题，提前告诉团队即可。

6.4 给新手的速记模板

方法再多，紧急情况下人会慌。我给新手准备了一个三行速记，覆盖三类环境的核心动作：

• 企业 Linux（RHEL/CentOS 系）：rw 加 rd.break，chroot 再 passwd，SELinux 别忘 autorelabel。
• Debian/Ubuntu 系：rw 加 init=/bin/bash，直接 passwd 后 reboot。
• 救援介质：先挂根，再 bind，chroot 前 LUKS/LVM 要激活。

记住这三行的核心不是背命令，而是理解目标：拿到可写的 root shell，改密码，修复登录相关坑。每个发行版只是实现路径不同而已。

先别嫌啰嗦，最后再分享一个真实体会。我第一次在新环境里做这类救援时，习惯先把原始内核参数拍照存到手机再动手改，看起来多此一举，但每次都能在最慌乱的时候帮我兜底。另一个体会是，能走到“重置 root 密码”这一步，往往说明平时的密码交接流程有问题。修好系统之后，把密码放进团队的密码保险箱，或者干脆关闭 root 密码登录、改用 sudo 加密钥管理，你大概率不会再经历第二次这种凌晨三点的尴尬。