从GRUB到shadow文件：Linux root密码重置完整指南

凌晨两点，手机屏幕在床头柜上疯狂震动。接起来是值班同事的声音：“哥，生产服务器的root密码好像被改过了，试了十几次都进不去，业务已经挂了，客户在催。”那一刻我脑子里只有一个念头：重置root密码。

这种场景，凡是做过运维或者管理过服务器的人应该都不陌生。系统能开机，磁盘没坏，数据就在那里，但你被一道密码挡在门外。更麻烦的是，现在很多环境不止一台服务器、一套系统——可能是云上的ECS，也可能是机房里的裸金属，还有可能是开着MySQL的数据库主机。标题叫“重置root密码”，但真到了动手的时候，你会发现这事情远不止“改个密码”那么简单：不同系统、不同引导方式、不同数据库、不同虚拟化平台，重置路径完全不一样，踩的坑也完全不一样。

这篇文章我就把自己这些年实际用过的、验证过的重置root密码的方法完整盘一遍，覆盖Linux本机、数据库、嵌入式设备、密码过期这类特殊场景，以及重置完之后必须做的收尾和安全处理。我不只给命令，还会说清楚每条命令背后的原理和每一步为什么要这么做。新手看完能照着操作，老手也能从中避掉几个平时容易忽略的坑。

1. 动手之前，先搞清楚你到底是哪种“忘了”

绝大多数人一看到“root密码重置”就直接去查GRUB怎么编辑、单用户模式怎么进。但以我个人的经验，至少有一半的“忘记密码”并不是真正意义上的忘记密码，而是“无法通过当前方式登录”。这两者的处理路径差别很大，先花两分钟定位问题，后面能少走很多弯路。

1.1 “密码忘了”不等于“登录不进去”

常见的尴尬情况就这几种：

• 密码还记得，但 sudo 切 root 的时候提示 root is not in the sudoers file，这是权限问题，不是密码问题。
• SSH 能通过密钥登录，但 root 用户的 SSH 密码登录被 PermitRootLogin no 禁掉了，想改用密码登录却不知道密码。
• 密码被 PAM 策略标记为过期，登录时提示 Your password has expired，但改密码又需要旧密码，陷入死循环。
• 密码是真的想不起来了，怎么试都是 Access denied。

这几种情况里，只有最后一种需要真正“重置”密码。前几种如果直接去改密码，虽然也能解决问题，但其实是绕远了，而且改完还可能引申出新的问题——比如改了 root 密码之后，原本能用的密钥登录如果配置不对，反而把自己锁在门外。

1.2 根据场景选择恢复路径

定位好是哪种情况之后，还要确认你手上有什么“通道”：

这张表看起来简单，但很实用。我见过不止一个同事在云服务器上抱着 VNC 窗口死磕 GRUB，结果发现云平台根本不给你中断引导的机会，最后还是回到“挂盘改 shadow”的路子上来。所以第一步永远是：先确认你有哪条路可以走。

1.3 动手前必须做的三件事

无论走哪条路线，有件事绝对不能省：确认数据的安全性。重置密码本质上是在系统运行时插入你的操作，一旦操作失误，轻则起不来系统，重则触发磁盘检查或 SELinux relabel 把整个环境搞坏。

动手前我习惯先做这三件事：

1. 如果是云服务器，先打一个快照或镜像备份，这个成本极低，但价值极高。
2. 如果是物理机/虚拟机，确认当前磁盘布局，尤其有没有 LVM 或 LUKS 加密分区。LUKS 加密盘在重置密码前必须先解锁，否则你连 / 都挂不上。
3. 把要执行的命令先在本地文本编辑器里敲好，不要进了紧急模式再去现想。紧急模式下没有补全、没有 Tab 提示，环境变量也经常不完整，手写命令很容易出错。

有朋友可能会问：重置个密码而已，至于这么兴师动众吗？我的回答是：任何一次对系统的“侵入式操作”，都应该当作一次小型变更来对待。密码重置尤其容易踩到 SELinux、read-only 挂载、加密盘意外锁定这些坑，多一道备份就多一条退路。

2. Linux 本机重置密码：三种标准动作与原理拆解

说完了准备工作，进入正题。这一章讲的是 Linux 本机（物理机或虚拟机）在能够接触控制台的前提下，重置 root 密码的三种标准做法。我会把每一步的原理都写清楚，这样万一系统变了、参数名变了，你也能根据原理临时应变。

2.1 CentOS/RHEL 7/8 系：GRUB 编辑 rd.break 方法

这是 CentOS 和 RHEL 系列最经典的做法，很多教程都写过，但对原理讲得很少。我重新梳理一遍完整步骤和每一步背后的逻辑。

第一步，重启系统，在 GRUB 启动菜单出现时快速按 e 进入编辑模式。注意时机窗口很短，通常只有几秒。如果机器启用了 GRUB 密码保护，这一步会先要求输入 GRUB 用户名和密码。这个密码是独立于系统 root 密码的，如果两个都忘了，那就只能考虑其他通道（比如云控制台的救援模式）了。

第二步，找到以 linux 或 linux16 开头的那一行，定位到行尾，在 rhgb quiet 后面追加一个参数：

code复制rd.break

然后按 Ctrl+X 或 F10 启动。

关键点来了：rd.break 的含义是“在 switch_root 之前中断启动流程”。系统会先加载 initramfs，把根文件系统挂载到 /sysroot，然后中断，给你一个 shell。之所以选在 switch_root 之前，是因为真正的根文件系统在这里已经被识别并挂载了，但还没有交接给系统主进程，所以你可以在这个 shell 里直接操作它。

进入 shell 之后，你会看到提示符变成类似 switch_root:/# 的样子。这时候执行：

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

第一条命令必须做，因为 rd.break 环境下 /sysroot 默认是只读挂载的。不重新挂载成读写，后面改密码会直接报 read-only file system。第二条命令把根目录切换过去，这样你就在真实系统的根环境里执行命令了。

然后就是改密码：

bash复制passwd root

输入两遍新密码，然后退出 chroot 和 shell，系统会继续启动。但这里有一个非常经典的坑：直接重启，系统会起不来，或者登录后再也进不去图形界面/服务异常，因为 SELinux 的安全上下文还是旧密码文件的状态。

正确做法是改完密码后，在 chroot 环境里创建一个标记文件：

bash复制touch /.autorelabel

这个文件的作用是告诉 SELinux 在下次启动时对整个文件系统重新打标签（relabel）。如果不做这一步，/etc/shadow 等文件的安全上下文可能不对，SSH 服务甚至可能因为无法读取密码文件而拒绝密码认证。创建之后退出、重启，系统会自动执行一次完整的 SELinux relabel，耗时取决于磁盘大小和文件数量，几分钟到十几分钟都可能的，需要耐心等。

2.2 Ubuntu/Debian 系：recovery mode 与 root shell

Ubuntu 的处理方式和 CentOS 类似，但入口更友好一些。开机时同样在 GRUB 菜单按 e 编辑，不过 Ubuntu 通常默认不显示 GRUB 菜单，此时需要按住 Shift（BIOS 启动）或连按 Esc（UEFI 启动）把菜单调出来。

找到 linux 开头那行，把行尾的 ro quiet splash 改成：

code复制rw init=/bin/bash

然后按 F10 启动。这里我直接用了 rw，让根文件系统以读写模式挂载，省得再去 remount。init=/bin/bash 则告诉内核：不要启动正常的系统服务，直接给我一个 root shell。

启动进去之后你会直接得到一个 bash 提示符，而且默认就是 root 身份。接下来执行：

bash复制mount -o remount,rw /
passwd root

即使一开始写了 rw，有些系统在启动过程中还是可能变成只读，所以手动 remount 一次比较保险。改完密码后执行 exec /sbin/init 或直接 reboot -f 重启。

Ubuntu 从 18.04 开始，root 帐号默认没有密码，登录用的是 sudo 方式。如果你只是想找回日常管理权限，其实不需要设置 root 密码，直接 sudo passwd 重置当前用户密码或配置 sudo 权限即可。只有在明确需要 root 直接登录的情况下，才去修改 root 密码。

2.3 云服务器/救援模式：挂盘 chroot 修改 shadow 文件

云服务器是现在最常见的部署形态。云上的一个关键约束是：你大概率没有物理控制台，GRUB 编辑的机会非常有限。所以云厂商普遍设计了“救援模式”或“重置密码”功能。这个功能底层逻辑就是：把系统盘从故障实例上卸载，挂到一台临时救援实例上，修改 shadow 文件后卸载、重新挂回。

如果你想手动操作，思路如下（以常见云平台为例）：

1. 在云控制台找到“救援模式”或“挂载系统盘”入口，启动救援实例。
2. 把目标系统盘挂载到救援实例（通常会自动挂载到 /mnt 之类的目录）。
3. 使用 chroot 进入系统盘：

bash复制chroot /mnt
passwd root

4. 退出后卸载磁盘，恢复原实例启动。

手动救援模式需要注意几点：挂载时尽量把原系统的 /proc、/dev、/sys 也绑定进来，否则 chroot 后有些操作会非常诡异；还有一点和前面一样，如果开了 SELinux，记得在 chroot 环境下执行 touch /.autorelabel。

如果云平台本身提供了“重置密码”按钮，那可以直接用，它内部会帮你完成这些操作。但别高兴太早，有些平台在重置密码后要求你重启实例才生效，而且这个过程中如果你开了 SELinux，同样有可能需要一段时间 relabel。生产环境重启用之前，注意评估影响窗口。

2.4 绕不开的特殊情况：GRUB 密码、LUKS 加密、TPM 绑定

本机重置说得差不多了，但还有几类“特殊情况”得单独拿出来聊。

第一个是 GRUB 密码保护。如果这台机器在安装系统时设置了 GRUB 密码，上面所有方式在第一步“按 e 编辑引导参数”就会被拦下来，没有密码连引导菜单都进不去。这种场景下，物理接触已经不够了，必须把磁盘拆下来挂到另外一台机器上操作。这个方案和云救援模式类似：把磁盘挂到别的机器，chroot 进去改 shadow 文件，同时也可以把 /boot/grub2/user.cfg 或 /boot/grub/grub.cfg 里的密码配置删掉或者重置。

第二个是 LUKS 全盘加密。如果 / 分区做了 LUKS 加密，那么即使你通过 rd.break 进入了 shell，也会发现 /sysroot 根本挂不上——它还是加密状态。这时必须要拿到 LUKS 密码或者密钥文件。这已经超出了“重置 root 密码”的范畴，而是“恢复磁盘访问权限”的问题。建议大家在规划全盘加密时，一定把恢复密钥（recovery key）打印出来放保险柜，否则一旦密码丢失，基本无解。

第三个是 TPM 绑定 / Secure Boot。新机器如果开了 Secure Boot，修改 GRUB 参数后签名校验可能失败。这种情况下优先走系统自带的恢复入口（recovery mode 如果允许），或者临时关闭 Secure Boot 再操作。但每台机器的 BIOS 差异很大，这里只能给个方向，具体还得看你的硬件平台。

这些特殊情况在真实环境里出现的频率不低。以我个人经验，越是“高可用”“高安全”的配置，重置密码时就越容易卡关。所以做系统规划时，就应该把“忘记密码的恢复路径”作为一个必选项写进方案。

3. 数据库 root 密码忘了：MySQL/MariaDB 的三种自救手段

运维世界里另一个人气很高的“忘记 root 密码”场景是数据库。应用连不上数据库，开发说 Access denied for user 'root'@'localhost'，DBA 登录上去一看，密码确实不对。这时候别慌，MySQL 和 MariaDB 都保留了官方的“自救模式”。

3.1 skip-grant-tables：最暴力但最有效

这是 MySQL 官方文档里就有的方式：跳过权限验证直接启动。具体做法：

先停掉数据库服务：

bash复制systemctl stop mysqld
# 或
systemctl stop mariadb

用 mysqld_safe 或直接以跳过权限表的方式启动：

bash复制mysqld_safe --skip-grant-tables --skip-networking &

注意 --skip-networking，这个参数在生产环境尤其重要。跳过权限表已经等于把数据库大门完全敞开了，如果再监听网络端口，内网其他机器也能直接连上来，那简直就是在裸奔。本地操作够用了，网络连接完全可以不需要。

启动成功后：

bash复制mysql -u root

这回不需要任何密码就能进入。进去先干一件事，让授权表立即生效：

sql复制FLUSH PRIVILEGES;

这一步很多人会忘记。因为 --skip-grant-tables 模式下，MySQL 默认不加载授权表，直接 ALTER USER 可能会报错或行为诡异。先 FLUSH PRIVILEGES 再改密码，能避免很多莫名其妙的问题。

然后执行：

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

如果 MySQL 版本比较老（5.6 及以下），用：

sql复制SET PASSWORD FOR 'root'@'localhost' = PASSWORD('VeryStrongP@ssw0rd');

改完退出，重启 MySQL 服务。需要留意的是，修改成功之前务必要确认你记得住新密码，而且这个密码要符合生产环境的复杂度策略——不然重置完密码马上又忘，那就真的只能再走一遍这个流程。

3.2 init-file：生产环境更温和的重置方式

mysqld_safe --skip-grant-tables 有个缺点：需要直接停服务、手工启动进程，操作过程中数据库完全不可用。如果你的 MySQL 是通过 systemd 管理，而且不想改变原有启动方式，可以考虑 init-file 方式。

它的原理是：MySQL 启动时会执行 init-file 里指定的 SQL 脚本，而且执行阶段权限验证还没完全启用，所以可以用来执行密码修改语句。

步骤如下：

先写一个包含密码重置语句的 SQL 文件：

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

然后修改 MySQL 配置文件 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段下添加：

code复制init-file=/tmp/mysql-reset.sql

重启 MySQL：

bash复制systemctl restart mysqld

启动完成后，密码已经修改。这时候务必立刻做两件事：删除 SQL 文件，去掉配置文件里的 init-file 行，然后再重启一次数据库。否则下次重启还会执行这个文件，等于是把重置流程再跑一遍。

这个方式的优势是全程不改变系统原有启动方式，也避开了手工启动带来的进程管理混乱。缺点是如果 MySQL 启动本身就报错，这种方式也可能无法生效，因为没有进程会去加载这个 init-file。

3.3 云数据库：别想了，直接走控制台

现在很多业务已经用上了云数据库（RDS 类），实例上你根本拿不到操作系统的 shell，skip-grant-tables 这种方式直接在机制上就不给你机会。云数据库重置 root 密码的正确做法就是走云控制台。

不同云平台叫法可能不同，但底层逻辑基本一致：在控制台找到“重置密码”或“账号管理”，输入新密码，平台会帮你完成内部修改。这个过程通常要求先释放实例的连接，即把数据库停掉一会，所以操作前一定要确认业务窗口。

这里还有个大坑：很多云数据库的控制台重置密码，针对的是“数据库管理账号”而非 MySQL 内部的 root@localhost。如果你的业务连接串用的是内部建的业务账号，重置管理员密码并不会影响业务连接；但如果你确实把 root 密码弄丢了，而且业务连接用的就是 root，那么重置完之后所有应用连接串都要改。

所以接到“数据库 root 密码忘了”工单时，我的第一反应不是去改密码，而是先查一下应用连接串里用的到底是不是 root。如果用的不是一个最小权限账号，这本身就是安全隐患，顺手开个工单把应用账号权限收一收才更实在。

3.4 密码重置之后，版本差异和认证插件别忘了

MySQL 8.0 之后默认认证插件是 caching_sha2_password，MariaDB 则还是 mysql_native_password 为主。如果你重置密码时用了老版本习惯的 PASSWORD() 函数，在 MySQL 8.0 上会直接提示语法错误或者不生效。正确做法是用 ALTER USER ... IDENTIFIED BY。

另外，重置 root 密码之后，如果应用侧是用老客户端连接，可能因为认证插件不兼容而报错。这时候可以在重置时顺手指定认证插件：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NewP@ssw0rd';

这样做的好处是兼容老客户端，但安全性上不如默认插件。生产环境特别是面向外网的数据库，我更推荐保留 caching_sha2_password，把客户端驱动升级到支持版本——别为了省升级的事，把数据库的安全等级拉下来。

4. 嵌入式设备和密码过期这类“特殊恢复”场景

前面讲的都是标准服务器、数据库，还有两类场景虽然不那么常见，但真遇到了会特别棘手：嵌入式 Linux 设备和密码过期/锁定状态。处理思路和标准 Linux 大同小异，但细节上差别很明显。

4.1 嵌入式 Linux 忘了密码：uboot 和 busybox 的世界

嵌入式设备（路由器、机顶盒、工控机、开发板）看起来黑盒子一样，但里面跑的往往是 Linux。这类设备重置 root 密码的方式，取决于它的引导链是怎样的。

以常见的 ARM 开发板举例：设备启动时先跑 u-boot，再加载内核和 initramfs，最终挂载根文件系统。如果设备有串口调试口，操作空间就大很多。在 u-boot 阶段可以尝试打断自动启动流程，进入 u-boot 命令行，用环境变量控制内核启动参数。例如在 u-boot 里设置：

code复制setenv bootargs 'console=ttyS0,115200 init=/bin/bash rw'
boot

这等价于前面 Ubuntu 方案里的 init=/bin/bash，让系统直接绕过正常启动流程，给你一个 root shell。之后就可以直接挂载根分区、修改 /etc/shadow 或 /etc/passwd。

但嵌入式设备的难点往往不在命令本身，而在于：

1. 根文件系统可能是只读挂载的（squashfs、erofs），需要先确认 mount 情况，把可写分区找出来。很多设备会把配置区单独放在 /data 或 /overlay，密码文件可能在这些位置。
2. 设备可能没有 passwd 命令。busybox 里不一定包含完整的 passwd，此时可以直接编辑 /etc/shadow 文件里的密码哈希。具体做法后面会讲到。
3. 设备可能没有 chroot、mount 这些命令。busybox 整合了大部分常用命令，但裁剪版可能缺失，需要靠 u-boot 阶段操作或外部挂载工具。

处理嵌入式设备时，我的经验是：永远用“最小干预”原则。能在 u-boot 层面解决的，不碰系统文件；能改配置文件解决的，不改二进制；能备份的完整跑一遍备份。这类设备资料少、版本杂，一旦操作失误变砖，恢复成本往往比服务器高得多。

4.2 密码过期和锁定状态：PAM 和 shadow 文件

另一种被忽视的“root 密码问题”是密码策略导致的过期锁定。系统提示 password expired，但修改密码时又要求输入旧密码，旧密码又不满足策略，人就被卡在中间。

这种情况的处理其实非常简单，关键在于理解密码状态存储的位置。Linux 用户密码状态存在 /etc/shadow 中，root 用户的记录形如：

code复制root:$6$xxxxxxxx$yyyyyyyy:18900:0:99999:7:::

字段含义分别是：用户名、密码哈希、上次修改时间（距 1970-01-01 的天数）、最短修改间隔、最长有效天数、警告天数、宽限期、失效日期、保留字段。

如果你能通过某种方式进入系统（单用户模式、救援模式、sudo），直接执行：

bash复制chage -d 0 root

这条命令的意思是：把 root 密码的“上次修改时间”设为 0，强制下次登录时修改密码。这是应对密码过期最干净的手段，不会改变原有密码本身，只是让密码状态回到“必须修改”的初始状态。

如果连 sudo 都进不去，需要直接编辑 /etc/shadow 文件时，可以把 root 密码字段改成空或删掉，相当于设置空密码。但注意，默认情况下很多系统的 SSH 服务会拒绝空密码登录，所以这种方式只适合控制台/单用户模式下使用，修改后要尽快设置正式密码。

/etc/shadow 中密码字段常见的特殊值是：

很多设备的“忘记密码”问题，其实只是 root 被锁定了，去掉 ! 前缀或者重新设置密码哈希即可。

4.3 “切换 root”与“重置 root”的关系

热搜词里有大量类似“切换root”“进入root用户命令”的内容。这虽然和“重置密码”不完全是一回事，但对很多新手来说，容易混淆。这里我花点篇幅理清一下。

在 Ubuntu 等默认禁用 root 密码的系统上，“切换 root”是用 sudo -i 或 sudo su -，而不是 su - root。如果你的用户有 sudo 权限，完全不需要知道 root 密码也能执行管理操作。所以很多情况下，你并不需要重置 root 密码，只需要：

bash复制sudo passwd root

这会直接给你设置一个新的 root 密码。注意：这个命令会修改 root 密码，但前提是当前用户有 sudo 权限。如果当前用户没有 sudo 权限，但系统上还有其他管理员用户，也可以由他们来执行。

反过来，如果你就是 root，但想改自己的密码，直接 passwd 即可，不需要旧密码。这一点很多人会忽略——root 重置自己的密码不需要验证旧密码，这是系统设计上的安全选项，所有类 Unix 系统都这样。

使用建议上，我认为日常工作应该坚持“最小权限”：不要图方便直接切到 root 操作，用普通用户加 sudo 的方式更安全。这样即使某天 root 密码忘了，也不会影响应急排查——你还可以通过 sudo 用户进入系统，甚至重置 root 密码。如果整个团队平时都直接 root 干活，一旦密码丢失，恢复成本就变成全员被动。

5. 重置完密码之后，必须要做的五件收尾事

密码改完了，系统能登录了，很多人觉得万事大吉。但以我的经验，这才是一半，甚至一半都不到。收尾工作做得不好，后续大概率会再踩坑。

5.1 验证所有登录路径，别把自己锁在外面

重置完密码后，第一件事不是去跑业务，而是把这条机器上的所有登录路径都验证一遍：

1. 控制台/单用户模式能正常登录。
2. SSH 能用新密码正常登录（如果 SSH 密码登录是开启的）。
3. sudo 命令能正常执行。

如果发现 SSH 密码登录不了，先检查 /etc/ssh/sshd_config 里的 PermitRootLogin 和 PasswordAuthentication 配置。有些安全加固过的机器默认禁止 root 远程密码登录，这是正常的，不要为了验证去改这个配置，除非你有明确的远程登录需求。

5.2 清理临时文件与历史操作痕迹

前面重置数据库密码时创建的 SQL 文件、重置系统密码时执行的命令记录，都要清理。特别是包含明文密码的命令，在 shell 历史里都是非常敏感的信息。

清理方法很简单：

bash复制history -c

或者直接删除包含敏感命令的历史文件：

bash复制rm -f ~/.bash_history

/tmp/mysql-reset.sql 之类的临时文件，改完密码后一定要删干净，并且确认 init-file 配置已经从配置文件里移除。

5.3 检查审计日志

这一步很少被提到，但非常重要：重置密码后，系统会留下登录、重启、提权相关日志。这些日志不仅是排查问题的依据，更是安全审计的线索。

Linux 下检查：

bash复制journalctl -u sshd --since today
grep "Accepted password" /var/log/secure

如果发现异常 IP 登录尝试、非预期时间的登录记录，说明这台机器可能已经被攻击过。这时候“密码忘记”的原因可能就不是“记性不好”这么简单了，而是要启动应急响应流程。

5.4 如果想最大程度避免再次“忘记”

密码管理这件事，表面上是个技术问题，本质上是流程问题。我见过太多团队把密码写在 Excel 里、放在网盘上、贴在显示器边，或者干脆“每个人都知道”的口头密码。这些做法在安全上全都不合格，但对于内部管理也不是完全没办法。

我更推荐用密钥管理系统而不是明文密码本。至少要做到：

1. root 密码放进公司统一密码保险库，且开启访问审计。
2. 多人共管时使用 pass 或 keeper 之类的工具，密码分享不经过聊天软件。
3. 每周自动检查一次 root 密码是否被改动过，通过对比 /etc/shadow 中密码哈希值是否变化即可。
4. 重要服务器开启带外管理（IPMI/iLO/云控制台），确保永远有“绕过操作系统登录”的通道可走。

5.5 顺手的提醒：别把“重置密码”当正常运维手段

最后说点实在的。重置 root 密码是运维的兜底技能，但它应该像一个消防灭火器——平时用不到，关键时刻能救命，但不能把它当作日常工具随手用。

我自己遇到过一个差点出事的场景：有台机器 root 密码忘了，我进 rd.break 改完密码后忘记创建 /.autorelabel，重启后系统在 SELinux relabel 阶段卡了非常久，业务方电话打爆，我在机房冷汗都下来了。从此以后我给自己定了一条铁律：只要在紧急模式里动过身份认证相关文件，touch /.autorelabel 绝对不可省，哪怕当时没开 SELinux，也顺手敲一下，成本极低，收益极高。

还有一次，在给 MySQL 重置密码时，因为用了 mysqld_safe --skip-grant-tables 却忘了加 --skip-networking，重置完成后发现内网有一台监控机器连进了数据库。虽然最终没发生数据泄露，但也让我深刻体会到：重置密码这种“看起来只是临时操作”的动作，一样需要保持完整的安全边界，绝不能在紧急时刻放弃最基本的防护原则。

重置 root 密码这件事，说到底是“在系统认为你不该进去的时候，通过设计好的恢复通道进去”。所以它真正的难点不是命令本身，而是你对系统恢复机制的理解、对每一步操作后果的判断，以及做完之后能不能把系统恢复到比原来更安全的状态。把这一整套流程想透、练熟，你就不需要再为“忘密码”满头大汗了。