飞翔的十号说实话，"root破解密码"这个说法多少有点吓人，但绝大多数人搜这个词，真不是要去搞什么黑客行为，而是自己手头的服务器、虚拟机、开发机的 root 密码忘了，或者接手一台老机器时前任没留下密码。所谓的"破解"，本质上是利用系统启动流程中认证机制尚未生效的时间窗口，以单用户模式或 emergency 模式重置 root 密码，这是每个 Linux 运维都应该掌握的基本自救手段。
这篇文章我会把 Ubuntu/Debian 系、CentOS/RHEL 7+、老版本 CentOS 6 这三大类主流场景的恢复方法都拆开讲清楚，包括每一步为什么这么做、原理是什么、常见的坑在哪里。还会聊聊哪些情况下这些方法会失效，以及恢复之后容易踩的连锁问题。适合刚接触 Linux 的新手，也适合需要快速解决问题的运维老手直接照着操作。
1. 先说清楚：root密码恢复的本质是什么
很多朋友第一次碰到 root 密码忘记时，第一反应是"能不能用工具破解"。其实对于本地操作系统来说，根本不需要也不可能去暴力破解密码哈希，你只需要在系统还没完全启动起来、登录认证还没接管之前，抢先拿到一个 root 权限的 shell，然后用 passwd 命令重新设置密码就行。
1.1 关键窗口期：认证生效前的 root shell
Linux 系统的启动流程大致是：BIOS/UEFI 加载引导器（GRUB），GRUB 加载内核，内核启动 init 进程（systemd 或 SysV init），然后才轮到登录管理器或其他服务验证用户身份。这个顺序意味着：如果你能在 GRUB 层面注入参数，让内核启动一个特殊的 shell 而不是正常的 init 流程，你就能在"系统正式运行之前"拿到一个 root 身份的终端。
这就是所有恢复方法的理论基础。打个比方：你家门锁坏了进不去，但你可以通过施工通道直接进入房子内部换一把新锁，而不是在门口猜密码。
1.2 适用范围与安全边界
这些方法只适用于你拥有物理访问权或控制台访问权的设备，也就是你自己的服务器、虚拟机、实验机。操作前最好确认这台设备确实归你管，或者你得到了管理员的明确授权。生产环境操作前一定要评估风险——多花两分钟做快照或备份，远远好过系统起不来时后悔。
另外也要提醒一句：手机 app、路由器固件上的"一键 root"或"破解 root 密码"属于另一类完全不同的技术路线，不在本文讨论范围内。如果你是想给 Android 设备提权，那需要走 bootloader 解锁、刷入 Magisk 等方案，和本文的 Linux 系统密码恢复完全是两码事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Ubuntu/Debian 系：通过 GRUB 编辑引导参数进入恢复模式
Ubuntu 和 Debian 系是目前个人开发者和中小公司使用最广泛的发行版之一。这类系统的恢复路径比较直观：开机时进入 GRUB 菜单，修改引导参数，把系统拉进一个 root shell，然后重置密码。
2.1 进入 GRUB 菜单的三种姿势
第一步是怎么看到 GRUB 菜单。如果机器上只装了一个系统，GRUB 默认可能不显示菜单直接进系统，你需要：
- 传统 BIOS 启动：开机后长按左 Shift 键。
- UEFI 启动：开机后快速连点 Esc 键，等 GRUB 菜单出现。
- 如果以上都不行，开机时狂按方向键上下，可以中断 GRUB 的自动倒计时，让它停在菜单界面。
看到 GRUB 菜单后，你有两条路：直接按 e 编辑默认启动项，或者进入 Advanced options 选 recovery mode。我个人的经验是，直接按 e 改参数更干净，因为 recovery mode 有时会加载额外的钩子脚本，多一层不确定性。
2.2 修改 linux 行，追加 init=/bin/bash
在 GRUB 编辑界面里，你会看到一堆以 linux（UEFI 下是 linuxefi）开头的行，里面包含 vmlinuz、root=UUID=xxx 之类的参数。把光标移到这行的末尾，加一个参数：
code复制init=/bin/bash
这里要解释一下：这个参数告诉内核，不要启动正常的 init 进程（也就是 systemd），而是直接启动一个 bash。因为系统还没有进入用户认证阶段，这个 bash 就会以 root 身份运行。从效果上说，你直接在操作系统"醒来"的第一秒就拿到了完全控制权。
改完后按 Ctrl+X 或 F10 启动。稍等片刻，你会看到类似这样的提示符：
code复制bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
root@(none):/#
别被这两行警告吓到，这是正常的，因为没有 init 进程管理终端任务。你现在就在 root shell 里了。
2.3 重置密码的关键操作
现在虽然有了 root shell，但根文件系统是只读挂载的。直接跑 passwd 会报错，因为 shadow 文件根本写不进去。你需要先把根分区重新挂载为可写：
code复制mount -o remount,rw /
然后执行：
code复制passwd root
按提示输入两遍新密码，看到 passwd: password updated successfully 就说明成功了。如果系统有多个分区，比如 /boot 或 /home 是独立分区，通常不用管它们，改密码只需要根分区可写即可。
最后退出：
code复制exec /sbin/init
或者直接重启：reboot -f。注意这里不建议直接按电源键硬重启，虽然理论上文件系统是干净的，但稳妥起见还是用命令。
2.4 Ubuntu 20.04+ 的补充：recovery mode 路径和 initramfs 卡住的应对
如果 init=/bin/bash 之后你发现卡在类似 (initramfs) 提示符，这说明根文件系统没有成功挂载，可能因为 LVM 逻辑卷或者加密分区。你需要手动激活卷组：
code复制lvdisplay
vgchange -ay
exit
让 initramfs 继续走到 bash。
另一个常见坑是 Ubuntu 的 recovery mode。如果你选择的是 Advanced options 里的 recovery mode，再选 root - Drop to root shell，进去之后第一件事也是执行 mount -o remount,rw /，否则 passwd 一定会失败。很多人卡在这一步，以为 recovery mode 进去就能直接改密码，结果每次都提示 permission denied，其实只差这一条命令。
3. CentOS/RHEL 7+：rd.break 进入 emergency 模式的完整操作
CentOS 7 之后的发行版使用 systemd 和 dracut 构建的 initramfs，老的 init=/bin/bash 方法虽然还能用，但官方更推荐 rd.break 参数。这个方法的关键在于：它在 initramfs 阶段、根文件系统还没真正切换前，就中断了启动流程，给你一个几乎纯净的 shell 环境。
3.1 为什么 rd.break 比 init=/bin/bash 更可靠
rd.break 是 dracut 提供的一个内核参数，全称是 break before switch_root，意思是在 switch_root（切换到真正的根文件系统）之前暂停。此时系统处于 initramfs 的临时环境中，提示符是：
code复制switch_root:/#
这个环境比 init=/bin/bash 更干净——没有多余的钩子脚本，没有 systemd 的干扰，所有硬件驱动也已经加载完毕。你只需要手工挂载真实的根分区，chroot 进去，就能安全地修改密码。
3.2 一步一步操作
- 重启机器，在 GRUB 菜单界面按 e 进入编辑。
- 找到以 linux16 或 linuxefi 开头的一行（CentOS 8/9 里可能显示为 linux），移动到行尾，追加参数：
code复制rd.break
- 按 Ctrl+X 启动，等待系统落到
switch_root:/#提示符。 - 此时系统根目录还是 initramfs 的临时根，真正的系统根分区被挂载在 /sysroot 下，而且是只读的。执行：
code复制mount -o remount,rw /sysroot
- 切换根目录到真实系统：
code复制chroot /sysroot
- 现在你就是真实系统的 root 了。重置密码：
code复制passwd root
或者用非交互方式：
code复制echo "你的新密码" | chpasswd
- 关键一步：CentOS 默认启用 SELinux，如果直接重启，新修改的 /etc/shadow 文件可能因为安全上下文标签不对而无法读取，导致你明明改了密码却进不了系统。解决办法是在 chroot 环境里执行：
code复制touch /.autorelabel
这个空文件会让系统在下次启动时自动重新标记所有文件的安全上下文。
- 退出 chroot，再退出 switch_root，重启：
code复制exit
exit
reboot -f
3.3 SELinux 标签问题的深入说明
很多新手在这一步翻车，改完密码重启后系统登录界面一直报错，或者干脆卡在启动过程。原因就是 /etc/shadow 文件的 SELinux 标签被 passwd 重写后变成了默认标签，但 SELinux 策略暂时不认。
加了 touch /.autorelabel 之后，重启时系统会用约几分钟到十几分钟遍历整个文件系统，重新打标签。这期间系统看起来像卡住了，实际上是在干活，千万别强行断电。等它跑完进入登录界面，问题就解决了。
如果不想等 autorelabel，也可以在 GRUB 参数里临时加 enforcing=0，以 Permissive 模式启动，但这个方法只适合临时应急，系统跑起来后 SELinux 还是处于受限状态。
4. 老系统 CentOS 6 与 init 体系的恢复路径对比
虽然 CentOS 6 已经停止维护很久，但我在实际工作中真的还遇到过不少老机器在跑，尤其是内网机房里的遗留系统。CentOS 6 使用 SysV init，没有 systemd，恢复路径比 7/8 更"原始"，但反而更简单：不需要 chroot。
4.1 CentOS 6 的操作流程
重启进入 GRUB，按 e 编辑，找到 kernel 开头的行，在行尾加：
code复制init=/bin/bash
按 b 启动，系统会直接落到类似 bash-4.1# 的提示符。此时根文件系统依然是只读的，执行：
code复制mount -o remount,rw /
passwd root
因为是直接引导真实系统的 bash，不需要 chroot，改完直接执行：
code复制reboot -f
如果 reboot 命令找不到，也可以先 sync 再按电源键重启，因为此时文件系统已经正确挂载，风险不大。
4.2 与 CentOS 7+ 方案的本质区别
CentOS 6 的 initramfs 相对简单，init=/bin/bash 会把内核直接引导到真实根文件系统的 bash 里，所以剩下的步骤就是 remount 和 passwd。
CentOS 7+ 的 initramfs（dracut 生成）功能更强，包含的设备驱动和钩子更多，系统启动流程也变成了"initramfs 阶段 -> switch_root -> systemd 阶段"。rd.break 把流程打断在 switch_root 之前，等于是让你先"进入"一个临时环境，再手工进入真实系统环境。所以必须走 chroot，否则 passwd 改的是临时环境的密码文件，重启后一切照旧。
这个差异也解释了为什么很多老运维第一次用 CentOS 7 破解密码时，改完发现密码没变——就是没 chroot 到真实系统。
4.3 另一个经典参数 single
CentOS 6 时代还有一个方法：在 kernel 行末尾加 single 或 1，进入单用户模式。这个方式同样会给你一个 root shell，但它有个前提：系统可能会在进入单用户模式时通过 sulogin 要求输入 root 密码，这在"忘了密码"的场景下就是个死循环。所以相比之下，init=/bin/bash 更直接，完全没有认证环节。
CentOS 7+ 里对应的是 systemd.unit=emergency.target 或 systemd.unit=rescue.target，但这两个模式同样可能要求 root 密码，不建议作为密码遗忘的首选方案。rd.break 才是专门为这种场景设计的。
5. 恢复后的验证、权限边界与常见连锁问题
密码改完不等于万事大吉，我见过太多人在"修改成功"之后又栽在别的地方。这一章把容易踩的连锁坑都列出来，省得你再走一遍弯路。
5.1 重启后登录失败的排查思路
如果改了密码但重启后登录不了，按顺序排查：
- 登录界面提示 password authentication failed：密码确实不对。检查上一轮操作是否忘了 chroot（针对 CentOS 7+），或者是否因为键盘布局问题输错了特殊字符。
- 卡在启动进度条或黑屏：大概率是 SELinux autorelabel 还没跑完，或者跑挂了。可以再进一次 GRUB，追加
enforcing=0看能不能绕过。 - 提示 Authentication token manipulation error：shadow 文件权限或标签出了问题。回到恢复环境，确认
/etc/shadow权限是 000 或 600，属主是 root:root。 - 提示密码已过期：系统设置了密码过期策略，重启后要求强制改密码。这时用新密码登录，按提示更新一次就好。
5.2 这些方法什么时候会失效
虽然以上方法覆盖面很广，但确实存在一些它们解决不了的情况：
- GRUB 设置了密码保护。如果 bootloader 层面有密码，进不了编辑界面，该方法完全失效。
- 根分区使用了 LUKS 全盘加密。initramfs 阶段需要输入解密密码，没有密码就停在解密界面，后面的步骤根本走不到。
- 云主机控制台没有 GRUB 中断能力。很多云服务器在控制台里按键盘无法及时中断 GRUB 自动启动，这时候要改用云厂商提供的救援模式或 VNC 高级选项。
- 物理机远程操作。如果你只有 SSH 访问而没有带外管理（iDRAC/IPMI），密码丢了就等于进不去机器，只能走机房现场或厂商救援通道。
5.3 root密码和sudo权限的关系
还有一个常见的认知误区：root 密码忘了，但当前还有普通用户能 sudo。这种情况根本不需要进恢复模式，直接：
code复制sudo passwd root
输入当前普通用户的密码，就能重置 root 密码。前提是当前用户在 sudoers 里有权限。这也是为什么我建议每台服务器至少保留一个有 sudo 权限的普通用户作为"后门"，不要把所有鸡蛋放在 root 密码这一个篮子里。
如果你连普通用户都忘了，或者没有普通用户，才考虑走恢复模式。另外注意，如果 /etc/sudoers 里配置了 NOPASSWD，sudo 不会询问当前用户密码，但这不等于你可以直接切换到 root——su - 依然需要输入 root 密码。
5.4 顺带一提：MySQL 的 root 密码和系统 root 密码是两码事
热词里很多人搜"mysql 忘记 root 密码"，这里提醒一句：MySQL 的 root 是数据库内部的账号，跟操作系统的 root 没有任何关系。忘记 MySQL root 密码，恢复思路完全不一样，常见做法是在配置文件里加 skip-grant-tables，重启 MySQL 后免密进入，再通过 SQL 语句更新 mysql.user 表里的 authentication_string 字段。过程虽然不复杂，但涉及数据库文件操作，一定要谨慎，不要和系统 root 密码重置混为一谈。
6. 几次实操后的复盘与值得养成的习惯
总结这些恢复方法之前，讲讲我自己的两段经历。
第一次在 CentOS 7 上重置 root 密码时，我按教程操作完，在 chroot 环境里明明看到了 password updated successfully，但重启后就是登录不进去。反复检查，最后才发现少了 touch /.autorelabel——SELinux 把新写入的 shadow 文件拦截了。当时要是知道这一步，能少折腾一个小时。所以后来我在任何 CentOS/RHEL 系统的密码恢复教程里，都会把 autorelabel 单独拎出来强调。
第二次是帮朋友处理一台 Ubuntu 20.04 工作站，用了 init=/bin/bash 直接进 root shell，passwd 改完密码，重启之后发现系统弹了个错误：root/.xauthority does not exist。原因是我的操作过程中因为根目录只读时跑了一些命令，把 /root 下的环境文件搞乱了。其实这不算什么大问题，删除或忽略即可，但它提醒了我：在恢复模式下，只做和密码重置相关的操作，不要随手跑无关命令。
经历过这些之后，我现在有几条固定习惯：
- 每台服务器创建后立刻设置 SSH 密钥登录，确保即使密码失效也能通过密钥进系统。
- 虚拟机做密码恢复实验前必拍快照，操作失误能在几分钟内还原。
- 生产环境优先走云厂商的救援模式，不到万不得已不在生产机器上直接改引导参数。
- 重大修改前先备份 /etc/shadow 和 /etc/passwd，虽然 passwd 命令本身足够可靠，但备份让人心安。
- 给 GRUB 设置一个密码，防止有人未经授权进入恢复模式修改 root 密码。设置方法是用
grub2-setpassword（CentOS）或grub-mkpasswd-pbkdf2（Ubuntu），这能堵住物理访问层面的安全漏洞。
这些方法看起来简单，但真要遇到"root 密码忘了"的时刻，每一条都能救命。如果你还没在自己的测试机上试过，建议挑一台虚拟机练一遍——练的不是命令本身，而是对启动流程的理解。只要理解了"认证生效之前拿到 root shell"这个核心逻辑，无论以后遇到什么样的发行版、什么样的新引导器，你都能顺着这个思路找到对应的入口。