GRUB菜单加密与修复全攻略：密码设置、应急救援与UEFI重建

GRUB 菜单加密和修复这两个技能平时看着不起眼真正出事的时候能救命。前阵子给一台物理机做安全加固我给 GRUB 加了密码后来同事改内核启动参数的时候手抖改坏了 grub.cfg结果机器重启后直接卡在 grub rescue 界面当时又找不到 Live 启动盘折腾了一晚上才把系统拉起来。另一台服务器则是密码忘了差点把系统数据全丢了才想起来可以从外部介质重置。这两件事凑到一起我觉得必须把 GRUB 菜单加密与修复的完整链路整理一下怎么加密、加密后忘了怎么办、配置改坏了怎么修以及最稳妥的 UEFI/BIOS 重建流程。这篇文章既适合刚接触 Linux 服务器运维的读者也适合那些已经在生产环境摸爬滚打、但还没系统梳理过这套操作的人。我会把每一个命令背后的原理讲清楚也会把我踩过的坑原原本本说出来。1. 为什么需要给 GRUB 上锁单用户救援模式这扇后门1.1 未加密 GRUB 菜单意味着什么很多运维新手对 GRUB 菜单的安全性没有概念总觉得开机界面按个 E 键不算什么大事。但实际上只要你能在物理机前接触键盘不进系统就能拿到 root 权限——这是大多数 Linux 发行版在默认情况下的真实状态。具体风险路径是这样的开机进入 GRUB 菜单后选中默认的内核条目按 E 键进入编辑模式在linux这一行末尾追加一个rd.break或者把ro改成rw init/bin/bash然后按 CtrlX 启动。系统会直接弹出一个 root shell或者让你在一个极简环境里以 root 身份修改密码。整个过程不需要任何账号密码也不需要任何工具全程不到三十秒。这里的关键在于Linux 的 initramfs 机制本身提供了这种进入单用户或维护模式的入口目的本来是方便管理员做救援但如果没有对 GRUB 菜单做访问控制这个方便就变成了任何人都可以利用的漏洞。机房裸机、共享测试服务器、需要满足合规要求的业务系统都会在安全基线里明确要求 GRUB 菜单必须设置密码。1.2 加密后能挡住哪些场景给 GRUB 菜单加密之后开机时会要求输入用户名和密码只有认证通过才能编辑启动条目或进入交互式救援模式。这样至少能挡住以下三类场景临时路过机房的人趁你不在的时候试图进入单用户模式改密码未授权的同事或测试人员在机器无人看管时动启动参数物理接触设备的审计风险让后续的操作记录有据可查不是说加密后绝对安全毕竟物理接触仍然可以拆硬盘、拔内存但 GRUB 密码把绝大多数停留在按键级别的攻击挡在了门外。给系统装上这层锁成本极低收益却很直接。1.3 什么环境下建议必须设置从我个人的经验看以下环境属于强烈建议必须设置的范围机房托管服务器没有带外管理卡或带外功能不完善涉及支付、账户、隐私数据的业务服务器教学实验室、共享开发机、多人公用的测试环境客户现场交付的硬件设备开机菜单如果裸奔验收时大概率被质疑如果你管理的是一台云服务器通过浏览器里的 VNC 控制台也能访问开机界面这类环境同样建议设置 GRUB 密码因为控制台账号一旦泄露GRUB 就成了第二道防线。2. grub2-setpassword 加密实操与 user.cfg 的底层逻辑2.1 加密的三个关键文件GRUB 菜单加密涉及几个核心文件先把它们的关系理清楚后面排查问题会轻松很多/boot/grub2/grub.cfg主配置文件由 grub2-mkconfig 生成里面定义了菜单条目。这里面的密码不以明文出现而是只存放对密码哈希后的检查指令。/boot/grub2/user.cfg存放 GRUB 超级用户账号和密码哈希的独立文件。系统默认的超级用户名是 root但这里的 root 与 Linux 系统里的 root 用户是两码事只是 GRUB 自己定义的管理员名称。/etc/grub.d/目录下的脚本生成 grub.cfg 时会被逐一执行其中01_users这类脚本负责把 user.cfg 里的认证配置注入到生成的 grub.cfg 中。当你用grub2-setpassword设置密码时工具会自动生成一个user.cfg里面的密码不是明文而是经过 PBKDF2 派生的哈希字符串。PBKDF2 是一种带盐的慢哈希算法它会反复迭代几千次让暴力破解的成本显著提高。GRUB 在启动时读取这个文件如果哈希匹配才允许进入菜单编辑或执行敏感操作。2.2 RHEL/CentOS 系的操作步骤在 RHEL、CentOS、Rocky Linux 这类系统上设置密码的标准流程很简单grub2-setpassword执行后会提示输入两次密码。工具会自动生成/boot/grub2/user.cfg。你可以用cat检查一下这个文件的内容cat /boot/grub2/user.cfg输出大概是这样的GRUB2_PASSWORDgrub.pbkdf2.sha512.10000.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX看到grub.pbkdf2.sha512.10000这个开头说明密码已经写入成功。这里的10000是迭代次数不同发行版可能不同但都无碍。注意在某些较新的系统里设置完 user.cfg 之后需要重新生成一次引导配置把认证逻辑合并进 grub.cfggrub2-mkconfig -o /boot/grub2/grub.cfg2.3 Debian/Ubuntu 系的另一种做法Debian 系系统的处理方式略有差异。如果系统里有grub2-setpassword也可以直接使用但更通用的是用grub-mkpasswd-pbkdf2手动生成哈希再写入配置文件grub-mkpasswd-pbkdf2输入你自己的口令后工具会输出一行哈希。把这段哈希拷贝下来打开/etc/grub.d/01_users写入类似下面的内容cat EOF set superusersadmin password_pbkdf2 admin 粘贴上一步生成的哈希 EOF然后重新生成配置update-grub这里我把超级用户名设成了admin尽量避免与系统 root 用户名直接对应能减少一部分混淆风险。2.4 加密常见问题速查现象原因处理方式开机不弹密码输入窗口user.cfg 未生效或 grub.cfg 未重新生成执行 grub2-mkconfig/update-grub 后重启输入正确密码仍无法编辑超级用户名不匹配检查 user.cfg 或 01_users 中 set superusers 的值更新内核后菜单变得无法编辑新生成的 grub.cfg 覆盖了认证逻辑重新执行 grub2-setpassword 并重建配置密码中含有特殊字符导致语法错误缺少引号包裹建议只用大小写字母和数字避免单双引号我在实际维护中遇到最典型的问题是设置完密码、更新了内核结果 grub.cfg 被重新生成后user.cfg 被某些脚本清理掉了。解决办法是设置完 user.cfg 后顺手备份一份到/etc/grub.d/或直接写进模板这样重建 grub.cfg 时认证逻辑就不会丢。3. 忘记密码后的正规救援路线Live 环境重置口令3.1 明确边界这是维护自己设备的恢复操作GRUB 密码忘了之后千万不要慌也不需要从网上找那些奇奇怪怪的破解方法。正规做法也是所有 Linux 发行版官方文档都认可的方案就是用你自己的 Live 启动介质进入系统挂载磁盘后重新设置密码。这个流程只适用于你本人管理的设备本质上跟用管理密码找回密码是一个性质。3.2 从 Live 系统挂载原系统实际操作分几步走。先用 Live USB 启动到桌面或命令行环境打开终端。先查一下磁盘分区情况lsblk假设原系统的根分区是/dev/sda3且/boot单独分区是/dev/sda2。先把根分区挂载上去mount /dev/sda3 /mnt mount /dev/sda2 /mnt/boot如果根分区没有单独拆分/boot就不需要第二步。然后再把系统运行所需的几个虚拟文件系统绑定进来mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys随后进入原系统的 root 环境chroot /mnt /bin/bash进入 chroot 之后整个环境看起来就像原系统本身你可以直接执行原系统里的命令。3.3 在 chroot 环境内重置密码此时重置 GRUB 密码就很简单了grub2-setpassword或者 Debian 系grub-mkpasswd-pbkdf2根据发行版选择对应命令。执行完毕后退出 chrootexit然后卸载所有挂载点umount /mnt/sys umount /mnt/proc umount /mnt/dev umount /mnt/boot umount /mnt重启系统就能用新密码进入 GRUB 菜单了。3.4 几个容易翻车的细节这个流程看起来简短但有几个细节非常容易出错。第一如果原系统用的是 LVMlsblk里看到的/dev/mapper/节点要先vgscan和vgchange -ay激活否则挂载会失败。第二如果磁盘开启了 LUKS 全盘加密Live 环境启动后要先执行cryptsetup luksOpen /dev/sda3 dora把加密卷打开然后挂载的是解密后的/dev/mapper/dora不是物理分区。LUKS 密码和 GRUB 密码是两个完全独立的密码丢了 GRUB 密码不需要动 LUKS 密码这反而是个安全保障。第三chroot 之前一定要挂载/proc和/dev否则部分发行版的grub2-setpassword命令会报错提示无法获取相关信息。我最后一次做这个操作时就是因为忘记挂/proc导致工具在黑名单检测阶段卡住检查了半天才发现是挂载不完整。所以每一步都别省略顺序也别乱。4. 手抖改坏 grub.cfg 后的现场急救三种自救路径4.1 故障现象与根因判断GRUB 配置文件被改坏之后有几种典型的启动表现卡在grub rescue提示符什么菜单都没有停在grub提示符可以输入命令但不知道引导内核在哪里菜单能显示但选中条目后提示error: file /grub2/x86_64-efi/normal.mod not found启动进入 initramfs 阶段后直接进入 busybox 维护模式这些现象对应的根因各不相同。grub rescue一般意味着 GRUB 主程序或配置文件彻底丢了grub说明核心模块还在但配置文件出错file not found多半是路径配置或分区识别有问题initramfs 维护模式则通常与根文件系统挂载参数有关。4.2 在 grub 提示符下纯手工引导如果你的机器还能进grub可以不用外部介质直接在提示符下手动引导。步骤如下set root(hd0,gpt2)其中(hd0,gpt2)是 boot 分区所在位置。不确定的话用ls命令查看可用分区再用ls (hd0,gpt2)/查看分区内容找到vmlinuz-*和initramfs-*.img这两个文件。继续执行linux /vmlinuz-6.8.0-31-generic root/dev/sda3 ro initrd /initramfs-6.8.0-31-generic.img boot这里的root/dev/sda3是指真正的根文件系统分区不是 boot 分区。如果根分区是 LVM需要写成root/dev/mapper/vgroot-lvroot并额外加insmod lvm加载 LVM 模块。我曾经在 grub 界面下试过一条命令一条命令地敲最容易被坑的就是分区编号。GRUB 的分区编号从 1 开始例如/dev/sda2对应(hd0,2)GPT 分区表上写(hd0,gpt2)。如果你不确定就靠ls探测路径看到grub/、/boot/grub/之类的目录出现那就是了。4.3 用 rescue 模式恢复 normal 模块如果卡在grub rescue说明连normal.mod这个核心菜单模块都还没加载。此时先想办法加载它set prefix(hd0,gpt2)/grub2 insmod normal normal这里假设 boot 分区是(hd0,gpt2)。insmod normal加载菜单模块normal命令会尝试读取 grub.cfg 并显示菜单。如果 grub.cfg 本身没坏这一步就能回到正常界面如果配置文件坏了则会回到grub提示符那就按上面 4.2 的方式手工启动内核。我遇到过一种情况prefix指向的路径正确但grub2和grub目录名搞混了。RHEL 系通常用/grub2Debian 系通常用/grub在 rescue 界面多用ls (hd0,gpt2)/确认目录名能少走很多弯路。4.4 进入 initramfs 维护模式修 fstab 的补丁式方案有时候 GRUB 菜单正常也能加载内核但系统启动到一半进入 busybox 维护模式报错说找不到根文件系统。这种通常是内核启动参数里的root写错或者 /etc/fstab 中根设备的 UUID 对不上。出现这种情况可以在维护模式里查看cat /proc/cmdline然后用blkid查分区的实际 UUID回到 GRUB 编辑模式把linux行里的root参数改成正确的内容。这里不需要外部介质临时改启动参数可以救急但要永久修复还得改 grub.cfg 或 fstab。5. UEFI 与 BIOS 两种固件下的 GRUB 重建流程5.1 先认清固件差异在动手重建 GRUB 之前先明确当前机器的固件类型因为 UEFI 和 BIOS 的安装目标完全不同。项目BIOSUEFI启动文件位置写在 MBR 或分区引导扇区写在 EFI 系统分区ESP的 /EFI/ 目录挂载点不需要额外挂载ESP 通常挂在 /boot/efi重新安装命令grub2-install /dev/sdagrub2-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idmygrub是否需要激活卷不需要可能需要 efibootmgr 管理启动项判断方法很简单ls /sys/firmware/efi下如果有内容就是 UEFI 模式没有内容则是 BIOS 模式。5.2 从 Live 环境完整重建 GRUB我自己的操作习惯是只要手头有 Live 介质就不在 grub 界面里反复试探直接用最稳妥的流程挂载系统、chroot、重装 GRUB、重新生成配置。具体步骤如下mount /dev/sda3 /mnt mount /dev/sda2 /mnt/boot mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys如果机器是 UEFI 模式还要额外挂载 ESP 分区。假设/dev/sda1是 ESP且原系统把 ESP 挂在/boot/efimount /dev/sda1 /mnt/boot/efi然后 chrootchroot /mnt /bin/bash在 chroot 环境里先重新安装 GRUB 到磁盘BIOS 模式grub2-install /dev/sdaUEFI 模式grub2-install --targetx86_64-efi --efi-directory/boot/efi --bootloader-idmygrub再重新生成配置文件grub2-mkconfig -o /boot/grub2/grub.cfg这个流程做完GRUB 就完整重建了。如果原系统带有其他操作系统比如 Windows在配置生成前先确保os-prober已安装并启用否则双系统菜单会丢失。5.3 重建之后密码策略要一起回顾在 chroot 环境里重新生成完 grub.cfg 后如果之前设置过 GRUB 密码此时 user.cfg 的内容不受grub2-mkconfig影响通常还在。但为了确保配置一致性我习惯在重建流程的最后再执行一次grub2-setpassword这样能确保新生成的 grub.cfg 里确实引用了认证信息而不是因为某些意外导致 user.cfg 丢失后菜单处于无锁状态。重启前先不要直接拔盘。我在 Live 环境下做过太多遍最忌惮的就是 ESP 分区挂载位置不对。有次我忘了挂/mnt/boot/efi默认把 ESP 挂到/mnt下面结果 grub2-install 把启动文件写进了一个普通数据分区重启后压根找不到引导项。切记--efi-directory指向的必须是你挂载的原系统 ESP而不是 Live 系统自带的那个。5.4 重建后验证清单验证项目预期结果开机出现 GRUB 菜单正常输入 GRUB 密码后可选内核正常默认内核能进入系统正常磁盘里存在 /boot/grub2/grub.cfg配置已生成UEFI 启动项里存在对应条目固件已记录6. 高频踩坑实录与必须养成的备份习惯6.1 我在实际操作中踩过的几个代表性坑第一个坑是直接手改 grub.cfg。有一次我在生产环境里想临时修改内核参数图方便直接编辑了/boot/grub2/grub.cfg改动了一个引号位置结果重启后系统直接进不了 GRUB 菜单。后来才知道grub.cfg 是自动生成文件任何手改的内容在下次grub2-mkconfig后都会被覆盖而且手改时极容易破坏语法结构。正确的做法是改/etc/default/grub和/etc/grub.d/下的脚本再执行生成命令。第二个坑是把 ESP 挂载错误。UEFI 机器重建 GRUB 时如果 ESP 不是挂在/boot/efi而是挂在别的目录grub2-install会把引导文件写进错误位置。我有一次在客户现场折腾了半天就因为这个挂载点的问题最后发现 EFI 目录下根本没有我预期的文件。第三个坑是双系统里的 Windows 被隐藏。重新生成 GRUB 配置后Windows 启动项消失了原因是/etc/default/grub里的GRUB_DISABLE_OS_PROBER被设为true。在 UEFI 时代这类跨系统引导依赖 os-prober 扫描 EFI 分区该项被禁用时自然检测不到其他系统。6.2 预防性备份的标准化操作我现在的习惯是只要对 GRUB 相关配置动手先备份一份当前可用的引导配置cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak然后改配置或者升级内核后再手动确认生成的配置没有异常。对于 GRUB 密码文件我会把 user.cfg 也做一份带时间戳的备份放到/root/backup/目录同时记录密码本身存到安全的地方。内核升级后旧内核的保留策略也属于备份的一部分。很多服务器上的/boot空间不大每升级一次内核就清理旧版本结果新内核出问题想回滚都回不去。我的建议是至少保留最近两个旧内核别急于清理。回滚操作也很简单重启时在 GRUB 菜单的高级选项里选旧内核即可不需要重新安装任何东西。6.3 验证步骤与最终检查无论你做了加密、重置密码还是重建 GRUB流程走完都不要急着拔掉启动介质。我在本地虚拟机和物理机上反复验证过以下三步是最稳妥的收尾动作重启前在 chroot 环境里执行grub2-mkconfig -o /boot/grub2/grub.cfg一次确认系统没有输出任何语法错误。重启后先停在 GRUB 菜单界面确认密码输入窗口出现并且可以编辑条目。进入系统后执行一次cat /boot/grub2/grub.cfg | grep superusers确认认证配置确实存在于生成的配置中。如果这三步都通过说明 GRUB 加密与修复工作已经圆满收尾。6.4 最后再分享一个小技巧如果你的机器有多块磁盘且不确定 GRUB 到底装到了哪块盘上最简单的办法是在开机时进入固件设置界面调整启动顺序把自己刚装过 GRUB 的那块盘放到第一位。不要凭记忆猜因为有些主板在 UEFI 模式下会自动创建多个启动项而某些启动项对应的还是旧的、已损坏的引导文件。物理机上我见过太多次明明重装成功了却还是启动失败的案例根因基本都是启动顺序没排对。GRUB 菜单加密与修复不是一个高频操作但每一次真正需要它时都处于系统最脆弱、最紧张的时刻。平时花十几分钟把用户密码设置好把配置文件备份好把这些排查思路记熟关键时刻能帮你省下大半夜的折腾时间。