第三世界的妖孽干运维这些年，“Linux 密码忘了”大概是我被问得最多的问题，没有之一。打电话过来的人通常不是刚入行的实习生，就是已经管了几十台服务器的老手——机器越多，越容易在某台新装的系统上随便敲了个 root 密码，转头就忘。第一次遇到这事大家容易慌，总觉得系统密码进不去了，只能重装。其实只要机器还在你手里、硬盘没有做全盘加密，这顶多算一个“找回钥匙”的过程，远没到重装的地步。
这篇文章我打算把几个最常见的场景一次说透：CentOS 7 / RHEL 7 系的 rd.break 方案，Ubuntu / Debian 系的恢复模式和 init=/bin/bash 套路，国产发行版（麒麟、OpenEuler 等）的操作差异，以及 Artifactory 这类第三方服务的应用层密码怎么处理。最后再聊一聊密码策略、过期提醒和新用户规范。全都是实际踩过的路子，可以直接照着做。
1. 重置密码前先弄明白：你手里到底握着什么钥匙
1.1 密码本质在哪：/etc/shadow 里的那串哈希
Linux 的用户密码不是存在 /etc/passwd 里的，那个文件里只有用户名、UID、家目录和 Shell。真正的密码哈希在 /etc/shadow，普通用户不可读，只有 root 和 shadow 组能查看。shadow 文件每一行对应一个用户，字段之间用冒号分隔，第一段是用户名，第二段是类似 $6$salt$hash 的加盐哈希，后面还有密码最近修改日期、最短使用期、最长有效期、警告时间等参数。
所以“重置密码”干的事情其实很简单：想办法拿到一个能写 /etc/shadow 的 root 权限环境，然后用 passwd 命令重新生成密码哈希写进去。所谓单用户模式、rd.break、init=/bin/bash，本质都是同一个思路——绕过正常登录流程，先进入一个可以修改 shadow 的环境。
我用一个生活类比给你讲：保险箱钥匙丢了，不是把保险箱砸了，而是找开锁师傅从锁孔进去换一套锁芯。你只要证明你确实“拥有”这台机器（物理能碰到、磁盘没加密），系统本来就预留了这些维护入口。这也是为什么很多系统要加 SELinux、磁盘加密、Secure Boot 来防“师傅太容易开锁”。
1.2 动手之前，先判断你的场景能不能走这条路径
不是所有“忘了密码”都适合直接冲去按键盘。我见过不少人在机房蹲了半天，结果发现这台机器连键盘都没接。动手前建议先看下面几个条件：
| 场景 | 能不能重置系统密码 | 关键前提 |
|---|---|---|
| 虚拟机（VMware / KVM 等） | 可以 | 能登录虚拟化平台，通过控制台访问 |
| 物理机现场（接显示器键盘） | 可以 | 有物理访问权限，能看到 GRUB 界面 |
| 物理机远程（机房托管） | 可以 | 有 IPMI / iLO / iDRAC 这类带外管理卡，否则得联系机房 |
| 云主机 | 一般可以 | 用云控制台里的 VNC / 远程连接功能，通常还需要服务商允许 |
| 全盘加密（LUKS） | 特殊处理 | 必须要有 LUKS 密钥，单纯重置系统密码救不了数据 |
有一条很扎心的经验：如果这台机器连 SSH 都断了，本地控制台也没有，那你只能通过管理卡或者云平台控制台进入。再退一步说，如果管理卡的密码也忘了，那就是另一套硬件层面的密码恢复流程了。网红词里常有人问“超微主板 IPMI 密码重置”“sr650 重置 BMC 密码”，这种属于带外管理模块，和系统 root 密码完全是两码事，一般要通过机箱跳线、Clear 跳针或者厂商工具来恢复。
回到正题，下面按发行版给出可以直接照做的操作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. CentOS 7 / RHEL 7 系：rd.break 方式重置 root 密码
2.1 rd.break 的原理：在根文件系统挂载前截停
CentOS 6 时代大家习惯进单用户模式，一条 init 1 搞定。到了 CentOS 7，systemd 把运行级别改成了 target，传统单用户模式被拆成 rescue.target 和 emergency.target，直接用旧的套路很容易踩坑。所以在 CentOS 7 / RHEL 7 以及后续的 CentOS 8 / Rocky Linux / AlmaLinux 上，我推荐用 rd.break。
rd.break 的内核参数会让系统在 initramfs 阶段、切换根文件系统（switch_root）之前就停进一个紧急 shell。此时真正的根分区还没有被正式挂载，但磁盘已经识别了，基本的 shell 工具也在内存里。系统会把真实的根目录挂到一个临时位置上，也就是 /sysroot。我们要做的就是把它改成可写，然后 chroot 进去，用正常的 passwd 命令改密码。
相比 init=/bin/bash，rd.break 的好处是它中断得更早，受 SELinux、LVM、NFS 的影响更小，对新手更友好。这也是我第一推荐的原因。
2.2 完整操作步骤
这是一套我在 CentOS 7、Rocky Linux 8 上都验证过的流程，照着敲就行。
-
重启服务器。在 GRUB 启动菜单出现的时候，用上下键选中要启动的内核，按
e进入编辑界面。 -
找到以
linux16开头的那一行（有些新版本可能写成linux），把光标移到这行的末尾，加一个空格，然后输入：
bash复制rd.break
-
按
Ctrl+X或者F10启动。系统会停在一个类似switch_root:/#的提示符。 -
把真实的根分区以可写方式重新挂载：
bash复制mount -o remount,rw /sysroot
- 切进真实系统环境：
bash复制chroot /sysroot
- 修改 root 密码，推荐直接设置两次：
bash复制passwd root
- 如果这台机器开启了 SELinux（CentOS 7 默认是 Enforcing），一定要执行下面这一步，否则重启后大概率登录异常：
bash复制touch /.autorelabel
- 连续输入两次
exit，先退出 chroot 环境，再退出紧急 shell，系统会继续启动流程。如果中间没报错，重启完成后就可以用新密码登录了。
注意：
touch /.autorelabel触发的 SELinux 标签重建会让系统在首次启动时多花几分钟时间，屏幕上看起来像卡住了。别急，等它自己跑完，这属于正常现象。
2.3 这步最容易翻车的细节
有几个小地方我见过很多人反复栽跟头，单独拎出来说。
第一，开机时 GRUB 菜单一闪而过。如果是 UEFI 引导，开机可能要按 Esc 或 Shift 才能调出菜单；传统 BIOS 一般按上下方向键就能暂停。实在抢不到菜单，可以先进 BIOS 把引导等待时间调长，或者在 /etc/default/grub 里改 GRUB_TIMEOUT，但那是后话，当下你得先能抢到菜单。
第二，Secure Boot 开着。Secure Boot 开启时，有些自定义内核参数或模块会被拦，特别是某些国产服务器。这种情况下你可能会卡在引导早期。这属于安全机制在起作用，符合预期；但作为维护人员，如果机器完全失联，而管理卡又能进去，可以先在 BIOS 里确认 Secure Boot 状态，再决定要不要临时调整引导验证策略。
第三，改了密码重启后还是登录不了。这里面九成的原因是没有执行 touch /.autorelabel，导致 /etc/shadow 的 SELinux 上下文不对。所以回到第 7 步，别偷懒。
第四，不要手动改 shadow 文件里的哈希。网上有一些教程教你先用 openssl passwd -6 生成哈希，再替换 shadow 里第二段的字符串。这个办法理论上可行，但很容易因为哈希格式、$6$ 参数写法、字段分隔符的问题，导致密码永远认证失败。用系统自带的 passwd 要稳妥得多。
3. Ubuntu / Debian 系：恢复模式与 init=/bin/bash 双方案
3.1 方案 A：恢复模式（recovery mode）最省事
Ubuntu 的 GRUB 菜单里通常有一个 “Advanced options for Ubuntu”，点进去能看到带 (recovery mode) 字样的内核条目。选中它启动，会进入一个简洁的恢复菜单，里面有 “root - Drop to root shell prompt” 选项，进去就是 root shell。
这一步有一个很多人都会踩的坑：进入恢复模式的 root shell 后，根文件系统默认是只读的。你需要先执行：
bash复制mount -o remount,rw /
然后再改密码：
bash复制passwd root
重启之后完成。整个过程比 CentOS 的 rd.break 直观不少，比较适合新手入门。
不过有一个细节要注意：Ubuntu 默认 root 没有密码，日常大家习惯用 sudo 用户。如果你是在恢复模式里给 root 设置了密码，它不会自动帮你恢复某个 sudo 用户的权限。如果你的目的是“sudo 用户也进不去了”，那在 recovery shell 里除了改密码，还要检查一下 /etc/sudoers 是否正常，必要时把目标用户加回 sudo 组。
3.2 方案 B：init=/bin/bash 内核参数改动
如果说恢复模式是“可视化操作”，那 init=/bin/bash 就是纯命令行的直给方案。
- 在 GRUB 菜单按
e编辑内核启动参数。 - 找到以
linux开头的那一行，把结尾的quiet splash去掉，加上：
bash复制init=/bin/bash
- 按
Ctrl+X启动。系统会直接进入一个 root 的 bash 环境，但要先手动把根分区重新挂载为可写：
bash复制mount -o remount,rw /
- 修改密码：
bash复制passwd root
- 让系统正常重启，建议先执行
sync再执行reboot -f。如果你直接按电源重启，某些文件系统缓存没落盘容易出问题。
这个方案在 Ubuntu 20.04 / 22.04 上实测是可行的。但有一个需要注意的前提：这个环境非常精简，如果系统没有安装最小化工具集，passwd 可能会缺失。遇到这种情况，用 3.1 的恢复模式才是更稳的选择。
3.3 小坑提醒：全盘加密和 systemd 环境
如果这台 Ubuntu 在安装时开了 LUKS 全盘加密，情况就完全不同了。单用户模式也好，init=/bin/bash 也好，都只是在“加密层之上”的操作，进系统前你仍然需要 LUKS 密钥。如果密钥也忘了，那基本上只能考虑从备份恢复数据，这不是重置密码能解决的事。
我现在的建议是：任何要在生产环境折腾引导参数的操作，先看看磁盘是不是 LUKS。lsblk、blkid 都能看到分区类型里有 crypto_LUKS 标识。如果有，准备好密钥再继续，否则就是白忙活。
4. 国产系统重置：麒麟、OpenEuler 等发行版的操作差异
4.1 麒麟与 CentOS 系几乎一致的操作路径
这几年国产系统在政企环境里越来越多，麒麟系统（银河麒麟、中标麒麟）的命令行操作和 CentOS 系非常接近。它的引导器同样是 GRUB2，编辑内核参数的入口、按键方式和 CentOS 7 基本没区别。也就是说，2.2 节里的 rd.break 全套流程可以直接往麒麟上套。
在实际操作中，我习惯先把系统引导到 GRUB 菜单，按 e 后看一眼内核启动参数是不是 linux16 开头。有些麒麟版本改成了 linux 前缀，这并不影响你追加 rd.break，只要找准那行就行。
OpenEuler 也一样，它虽然不是直接基于 RHEL，但操作习惯上保留了很多 RHEL 的影子。如果只是重置密码，完全可以按 CentOS 的教程来。遇到实在进不去的情况，记住一个通用兜底：用系统安装 ISO 启动，进“救援模式”或“安装介质修复”，效果和你手动改 grub 参数达到目的是一样的。
4.2 国产系统上值得注意的引导差异与安全校验
有几个差异点需要单独提醒。
一个是国产服务器的固件引导界面。飞腾、鲲鹏、龙芯等平台的 UEFI 界面虽然也符合标准，但按键逻辑、启动菜单入口可能和 x86 平台不太一样。比如有些平台要按 F2 进固件设置，按 F7 或 F11 才能进一次性启动菜单。这不算系统问题，但真到了现场，你先得确认“按哪个键能进 GRUB”。
另一个是某些国产系统在编辑 GRUB 前会要求输入固件管理员密码。这是平台安全策略，不是 Linux 的一部分。遇到这种情况，你打 passwd 也没用，得先找硬件层面的人解开固件锁。这也是为什么我反复强调，重置系统密码之前，先确认带外管理密码、固件密码这些“硬件钥匙”是否可用。
另外，麒麟这类系统默认也可能开启 SELinux。rd.break 重置完成后，同样要留意是否需要 touch /.autorelabel。我一般不作假设，直接执行一次也不吃亏。
5. 服务层密码重置：Artifactory 等第三方应用怎么办
5.1 先分清是系统密码还是应用密码
很多人把“Linux 重置密码”理解成“只要进了系统就能搞定一切”，但其实还有一个高频场景：系统能进，但某个应用的登录密码忘了。比如热搜里常见的“artifactory 重置密码”，这说的就是 JFrog 制品库管理后台的 admin 密码。
这类问题如果还按系统密码的思路去搞，就容易南辕北辙。你即使把 root 密码重置了，Artifactory 的 admin 账号也不归 /etc/shadow 管，它是应用自己维护的一套用户体系。所以第一步永远是：确认密码存在哪。
- 如果是系统账号密码：走前面几章的发行版方案。
- 如果是应用账号密码：先查应用的用户存储方式，是本地文件、数据库还是 LDAP/AD。
- 如果是数据库账号密码：改的是数据库实例的认证信息，和操作系统又是另一层关系。
5.2 以制品库、GitLab 等常见服务为例的通用排查思路
以 Artifactory 这类基于 Access 组件的制品库来说，admin 密码忘了，官方通常提供恢复机制。大方向是先停止服务，找到安装目录下用于重置管理员密码的维护命令，执行时它会强制你重新设置密码。操作顺序一般是：停止服务 → 备份数据目录和数据库 → 执行官方重置命令 → 启动服务 → 用新密码登录后立刻修改。
GitLab 是另一个典型例子。它内置了 Rails runner，重置 root 密码的方式非常标准：
bash复制gitlab-rails runner "user = User.find_by(username: 'root'); user.password = '新密码'; user.password_confirmation = '新密码'; user.save!"
这个命令最关键的地方在于，它会走 GitLab 自己的密码加密逻辑，所以密码能正常通过校验。如果手动去改数据库里的哈希，十有八九会因为加密方式不一致导致登录失败。
再比如 Nexus、GitLab CI 里的 runner token，这类应用级的凭证通常也有对应的 CLI 或 API 重置接口。我的建议是：不要一上来就动数据库，先翻当前版本官方文档里关于“reset admin password”的内容，用厂家提供的工具。
5.3 重置第三方应用密码的几个通用原则
结合这些年的经验，我把应用层密码重置提炼成四个通用原则，适用于 Artifactory、Nexus、GitLab、JumpServer 这类自建系统：
第一，备份先于一切。应用数据目录、配置文件、数据库都要备份，不然重置到一半发现应用起不来，你会非常被动。
第二，确认密码的最终存储位置。如果应用接入了 LDAP/AD，你重置本地 admin 密码可能根本没用，因为认证根本没走本地。先看配置里的认证源。
第三，尽量用官方命令，而不是改数据库。改数据库是最后手段，除非你能确定密码哈希的算法和字段格式，否则很容易把整个账号体系搞坏。
第四，重置后验证再收工。重启服务后，用新密码登录一次，确认权限组、API token 都正常，再离开现场。我遇到过很多次“密码看起来重置成功了，但实际账号被锁定”的情况，就是因为忽略了应用自身的账号锁定策略。
6. 别再等忘密码才行动：密码策略、提醒与用户管理
6.1 用 chage 控制密码过期与提醒阈值
重置密码只是补救，防得住才是本事。Linux 内置的 chage 命令就是管密码生命周期的，我建议每台服务器都给它设一个合理的过期策略。
查看某个用户的密码策略：
bash复制chage -l root
设置策略：密码有效期 90 天，提前 7 天开始提醒，过期后 3 天内必须修改：
bash复制chage -M 90 -W 7 -I 3 root
其中 -M 是最大有效天数，-W 是提前警告天数，-I 是宽限期。设置完成后用户在登录时就能看到类似“Warning: your password will expire in N days”的提示。
如果要实现邮件提醒，可以写一个脚本，定期读 /etc/shadow 里的过期字段。shadow 的第三、第四、第五个字段分别对应最近修改日期、最短天数、最长天数。脚本逻辑就是算出密码还有几天过保，小于阈值就发邮件给运维人员。这个思路比依赖人工记忆可靠得多。
经验提醒：root 密码如果设置了过期，SSH 远程登录会被挡在认证环节，只能在本地控制台登录后修改。所以提醒阈值不要设得太短，尤其是你只有远程通道的时候。
6.2 新建用户和 sudo 组的规范操作
密码管理不只是 root 一个账号的事。我强烈建议：新装完一台 Linux 后，第一时间创建一个日常用的 sudo 用户，把 root 密码随机化存到密码库里，平时谁也不要直接用 root 干活。
创建用户的标准操作：
bash复制useradd -m -s /bin/bash zhangsan
passwd zhangsan
赋予 sudo 权限，CentOS / RHEL / 麒麟等系统用：
bash复制usermod -aG wheel zhangsan
Ubuntu / Debian 系用：
bash复制usermod -aG sudo zhangsan
注意一个细节：-aG 的 -a 千万不能丢，否则会把用户从原来的附属组里全部移出去。我见过一个同事只敲了 usermod -G wheel zhangsan，结果用户失去了好多基本组权限，反而弄出一堆问题。
对不再使用的账号，及时锁定：
bash复制passwd -l zhangsan
-l 会在密码前加 !，锁住后该用户就无法登录了。这是保留账号数据前提下最干净的“封禁”方式。
6.3 我的习惯：把“忘密码”从事故变成小事
我管过的服务器比较多，踩过几次坑之后养成了一个习惯：每台机器的 root 密码和重要服务密码都记录进密码管理工具，同时每个季度轮换一批关键密码。听起来麻烦，但真到事故现场，你省下的时间不是按小时算，是按分钟算的——每一分钟都是业务恢复时间。
另外，重要生产机器我都会保留一个“逃生账号”，也就是一个拥有 sudo 权限的非 root 用户，密码独立设置。这样即使 root 密码完全丢失，还可以用普通账号 sudo 绕进去，处理很多问题，不必每次都在 GRUB 上折腾。
7. 常见问题与排查技巧实录
7.1 问题速查表
下面这张表我压了几年现场经验，基本能覆盖 90% 的“重置密码后出问题”场景：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 开机后 GRUB 菜单一闪而过 | 超时太短或 UEFI 菜单没出现 | 开机按 Esc/Shift，或进 BIOS 调整引导等待时间 |
| rd.break 启动后停在奇怪的地方 | Secure Boot 或固件安全策略拦截 | 先确认固件设置，再从管理卡/控制台一步步排查 |
| chroot /sysroot 后 passwd 报错 | 根分区没挂载为可写 | 重新执行 mount -o remount,rw /sysroot |
| 重置完重启，登录提示认证失败 | 没执行 touch /.autorelabel，SELinux 上下文异常 |
重新走一遍流程，这次记得执行它 |
| Ubuntu recovery 模式下改密码失败 | 根文件系统仍为只读 | 先执行 mount -o remount,rw / 再改 |
| root 密码改完，SSH 还是连不上 | sshd 默认禁止 root 远程登录 | 通过本地 console 登录，或调整 /etc/ssh/sshd_config |
| 密码没忘，但登录提示已过期 | 密码策略过期 | 本地控制台登录或用 chage 修改过期策略 |
| Artifactory admin 密码重置后仍无法登录 | 应用账号被锁定，或接入了 LDAP | 停服，按官方恢复流程重置并检查认证源 |
| 明明进了紧急 shell，看不到任何磁盘 | 系统是 LUKS 全盘加密 | 需要 LUKS 密钥，用救援环境解锁后再 chroot |
7.2 几个现场踩坑后的心得
这些年下来，我觉得最重要的是心态。重置密码的技术难度不高，真正难的是在服务器前千万别乱按。
第一个心得是**“快照”永远是后悔药**。在虚拟化平台上操作之前，先给虚拟机做一次快照。哪怕你把 GRUB 参数改坏、把 SELinux 标签搞乱，大不了回滚快照重来。物理机虽然没有快照，但如果是带外管理卡能远程挂载 ISO，那也是另一个维度的“后悔药”。
第二个心得是做完一定要验证，而且要验证两次。第一次验证是重置密码后立刻本地登录一次，第二次是重启一遍确认自动启动没问题。我知道很多人嫌重启麻烦，可真实生产环境里，你写了一个 /etc/fstab 或者改了一堆内核参数后，如果不验证重启，下次重启可能就再也起不来了。
第三个心得是控制台路径要提前确认。云平台的控制台、机房的 KVM-over-IP、虚拟化平台的控制台，这些入口在平时没人关心，真到忘密码的时候，它是你唯一救命通道。我建议每季度和团队对一遍自己负责机器的带外管理地址和登录方式，这比事后到处找联系方式靠谱得多。
最后一个心得比较反直觉：改密码前先想好怎么告诉别人新密码。重置完成、验证通过之后，第一时间把它同步到密码管理库，告诉相关同事。不然你前脚刚走，后脚同事发现密码忘了又开始新一轮折腾——这种“重置完等于没重置”的循环，我在团队里见过太多次了。
我个人在实际操作中最常用的一句话是：密码忘了不要慌，先看清楚这机器你有多少把钥匙，再决定开锁方式。系统密码走系统通道，应用密码走应用通道，硬件密码走硬件通道，路径对了，剩下的就是时间问题。