银河麒麟V10密码重置与账户锁定解除的完整实战指南

接到过不少银河麒麟V10忘记密码的求助，有桌面版办公电脑，也有机房里跑着业务的服务器。最常见的梗就是“昨天刚设置的密码，今天死活想不起来”，还有一种更坑——不是忘了密码，而是登录界面输入错误太多次，被系统直接锁了，提示“为安全考虑，已锁定该用户账户”，不懂的人一下就懵了。

坦白讲，银河麒麟V10的密码重置方法和其它Linux发行版思路大体一致，但细节差异很多：桌面版和服务器版分支不同，CPU架构从x86到飞腾、鲲鹏都有，GRUB菜单的进入方式也不同，甚至部分系统启用了SELinux、PAM账户锁定策略。如果开头就判断错场景，很可能重置完密码依旧登不进去。这篇内容是我处理这类故障的完整经验，按场景拆成几条可行路径，每一步会解释为什么这么操作，哪些坑要先避开。

1. 动手前先分清版本和场景：走错路可能比忘密码更麻烦

很多人拿到一台忘记密码的V10机器，上来就想找“万能命令”，实际上真正要做的第一件事是判断这台机器的具体情况。不同场景的解决方案差别很大，盲目操作轻则白忙活，重则把系统搞到起不来或数据丢失。

1.1 四个决定后续操作方向的问题

按照我的处理习惯，会先问自己四个问题：

第一，桌面版还是服务器版？ 银河麒麟V10有桌面版和服务器版两个大体系，默认软件包、PAM配置、是否开启SELinux都不完全一样。桌面版通常预装图形登录界面，账号锁定策略和钥匙环管理更贴近日常办公场景；服务器版更偏向命令行环境，部分版本的登录认证配置会更严格，甚至默认禁止root通过SSH远程登录。

第二，目标账户是root还是普通用户？ 如果是普通用户，只需要有任意一个sudo/root权限账户，登录后执行一条passwd 用户名就能解决；如果是root账户本身忘了密码，那就必须走重置流程。这和Windows忘记管理员密码后只能在PE里操作是一个道理。

第三，机器是什么CPU架构、引导方式是什么？ 麒麟V10经常部署在飞腾D2000、鲲鹏920、龙芯3A5000以及兆芯等平台，也支持x86。不同架构虽然GRUB编辑思路一样，但LiveCD救援环境的架构必须匹配——用x86的Live环境去挂载ARM系统分区，chroot进去后会发现指令集不兼容，根本跑不起来。另外UEFI引导和传统BIOS引导下进入GRUB菜单的按键时机和界面风格也有差异。

第四，是否启用了全盘加密或磁盘卷组？ 如果系统在全盘加密基础上运行，那么重置密码前必须先能解开加密层。开机时会要求输入加密口令，而不是登录密码——如果这个口令也丢了，后续的单用户和LiveCD方案都会卡在解密环节。大多数默认安装的V10办公系统不会主动启用全盘加密，但服务器上有可能。

1.2 一个简单的场景判断表

这些判断往往在五分钟内就能完成。先把机器的硬件平台、系统版本、当前能进到哪一步、有没有其它可登录账户摸清楚，后面再按方案走就会顺很多。

2. “为安全考虑，已锁定该用户账户”不是密码错误，先搞清楚锁的是哪一层

有相当一部分人找过来时，原话是“密码忘了，因为登录界面提示已锁定”。我让他们再描述一下，发现很多人并不是密码不对，而是连续尝试了多次错误密码，系统直接把账户临时锁住了。这种“被锁定”和“忘记密码”是两回事，处理方式完全不同。

2.1 锁定机制是怎么触发的

麒麟V10在图形登录和命令行认证中普遍集成了PAM的账户锁定模块，通常是pam_faillock，部分旧版本会看到pam_tally2。机制很简单：连续输错密码的次数达到阈值（常见的是3到5次），PAM模块会把这个账户标记为锁定，在锁定时间窗口内即使输入了正确的密码也会被拒绝。

登录界面会显示一段明确的提示：“为安全考虑，已锁定该用户账户，原因是登录尝试或密码更改尝试过多。请稍候片刻再重试。”看到这句就意味着账户层面被“临时冻结”，不是认证密码本身出问题。

这里有一个关键认知：错误尝试的记录很多情况下存放在/var/run/faillock/这样的临时目录中，而/var/run在部分系统里是tmpfs，意味着系统重启后计数会清零。如果只是等待，锁定时间到了也会自动恢复；但如果系统不重启，清理最快的方式就是手动重置计数。

2.2 root密码可用时，解锁操作很简单

已知root密码，且有办法进入root环境时，解锁一个被锁定的普通用户只需要执行：

bash复制faillock --user 用户名 --reset

如果是较老的V10版本，系统中没有faillock命令，可以试试：

bash复制pam_tally2 --user 用户名 --reset

这个命令会删除该用户的所有失败登录计数，效果等同于刚重启过系统。很多人在图形登录界面被锁后，会直接重启机器，其实重启后计数大概率也会清零，但生产环境的服务器不能随便重启，所以还是用命令行重置稳妥。

2.3 账户锁定的同时root密码也忘了怎么办

真正麻烦的是这种组合：普通用户被锁定，root密码也想不起来。那就不能只清计数了，要先通过重置流程把root密码改掉，进入系统后再用faillock --user 用户名 --reset清掉被锁账户的计数。

需要特别注意顺序问题。有人想得很简单：先重启进入单用户模式把普通用户的密码改了，结果回到登录界面依然提示“账户已锁定”。原因就是faillock的锁定记录没有清，光改密码不解决账户层冻结的问题。所以正确的顺序应该是：重置密码后，紧跟着清理失败计数，否则看到的现象和重置前一样——依旧是“已锁定”。

2.4 关于shadow文件里的密码字段，别乱清空

很多网上的旧教程会让人进入单用户模式后直接编辑/etc/shadow，把密码哈希删掉，或者把密码字段前面加个!号来“解锁”。这个方法听着简单，但翻车概率极高。/etc/shadow每一行对应一个用户，各字段之间用冒号分隔，第二个字段就是密码哈希。某些状态前缀有特殊含义：

如果直接清空密码字段，很多V10图形登录界面默认不允许空密码登录，而且还会触发密码已过期提示，最后卡在另外一道坎上。除非你能确认PAM配置中允许空密码，否则不要走这条路。

3. 方案A：编辑GRUB启动参数直接重置密码

这套方案适用于root密码忘记、机器有物理控制权限、GRUB菜单没有被额外口令保护的情况。不需要额外的U盘或光盘，利用系统自带的引导流程就能完成重置，也是我最常用的处理方式。

3.1 进入GRUB编辑界面的时机

开机后观察屏幕，当出现GRUB菜单（通常列出系统内核版本）时，按下键盘上的e键，进入启动项编辑界面。如果开机时看不到GRUB菜单，V10桌面版有时会配置为隐藏菜单，需要在开机自检后快速连按Shift或Esc键尝试唤出。

编辑界面就是类似Vim的纯文本启动项配置，找到以linux或linuxefi开头的那一行——UEFI引导的机器常见linuxefi，传统BIOS引导常见linux。这一行的参数中有root=、rhgb、quiet等内容。

用方向键把光标移动到行尾，注意是linux行而不是initrd行。在行尾删除或保留rhgb quiet不影响核心逻辑，重点是追加启动参数。追加rw init=/bin/bash，完整效果类似：

text复制linux /boot/vmlinuz-xxx root=/dev/mapper/klx-root rw init=/bin/bash

其中rw表示根文件系统以可读写方式挂载，init=/bin/bash表示内核启动后不再执行完整的systemd初始化流程，而是直接进入一个bash root shell。

修改完后按Ctrl+X（有时候是F10）启动，系统会绕过登录界面，直接进入一个root命令提示符。

3.2 两种不同内核分支下的实际操作

由于银河麒麟V10本身存在多个发行分支，有的基于Debian/Ubuntu体系的initramfs结构，有的更接近RHEL/CentOS体系的启动链路，所以实际进入环境后，根文件系统的挂载状态和所在路径会不太一样。通常分两种情况处理。

第一种，直接进入bash shell环境：

执行下面的命令确认根目录读写状态：

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

如果是修改普通用户的密码，把passwd root换成passwd 用户名即可。系统会提示输入两次新密码。注意root用户通常不受密码复杂度策略限制，但普通用户会受pam_pwquality模块的强度检查影响，设置太简单的密码会报BAD PASSWORD，需要按提示输入更复杂的密码。

重置成功后，如果系统开启了SELinux，建议执行一次：

bash复制touch /.autorelabel

这一步能确保重启时SELinux自动重标文件上下文，否则后面会被SELinux拦截，登录时出现各种诡异问题。随后执行exec /sbin/init或reboot -f重启系统。

第二种，进入的是switch_root/initramfs环境：

有些服务器版V10要在linux行尾加的参数是rd.break，启动后会进入initramfs的紧急shell，提示符一般不是常规的root路径。这种情况下根系统被挂在/sysroot下，并且默认是只读的。需要执行：

bash复制mount -o remount,rw /sysroot
chroot /sysroot
passwd root
touch /.autorelabel
exit
reboot

顺序不能乱。chroot之前如果不先把/sysroot重新挂载为可读写，后面passwd会直接报文件系统只读，无法写入密码。

两种方式的差异和适用判断：

如果一种方式进不去，重启后换另一种再试。绝大多数V10版本要么能直接进入bash，要么能进入sysroot环境，两条路径基本覆盖。

3.3 进入单用户模式后常见的报错与解决

执行passwd时报错cannot lock /etc/passwd或Authentication token manipulation error，大概率是根文件系统还是只读状态。很多教程只说“启动参数里加init=/bin/bash”，却不说默认情况下根文件系统在只读状态，导致新手在这里卡很久。解决方式就是先执行mount -o remount,rw /。

如果系统在进入bash后网络服务、键盘布局等有些功能不可用，不要慌，单用户模式本来就是个最小化环境，只需要能执行命令就行。

有一点要提醒：如果开机时GRUB菜单需要密码才能编辑，那么“按e进入编辑”这个操作本身就会要求输入GRUB密码。GRUB密码不是用户密码，而是管理员在安装或加固系统时额外设置的引导口令。这种情况用方案A进不去，只能跳到LiveCD救援方案，或者找当时设置GRUB密码的人。

4. 方案B：GRUB进不去时用LiveCD救援模式chroot修改密码

GRUB被口令保护、系统启动失败、或者引导菜单完全起不来时，单用户模式路线就走不通了。这时候需要准备一个LiveCD引导环境，从外部挂载系统盘，用chroot方式进入原系统修改密码。

4.1 准备一个同架构的Live环境

LiveCD不一定非得是银河麒麟官方镜像。只要能启动到Linux环境、架构和系统盘一致就行。x86机器用x86的Ubuntu Desktop或Fedora Live ISO都没问题；ARM架构（飞腾、鲲鹏）就要找对应的ARM64 Linux Live环境，用x86的live系统引导ARM机器本身就起不来。

U盘制作方法很简单，Linux下用dd写入镜像，Windows下可以用常见的写盘工具。需要留神的是dd目标设备不要写错，比如：

bash复制dd if=live.iso of=/dev/sdb bs=4M status=progress

这里/dev/sdb是U盘设备名，如果写成了/dev/sda（原系统盘），整块系统盘会被直接覆盖。我见过太多“忘记密码后想用U盘恢复，结果把系统盘写没了”的惨案。对不熟悉的机器，强烈建议先执行lsblk确认设备对应关系，拔掉U盘看一次、插上再看一次，确认新出现的设备就是U盘。

4.2 从Live环境挂载原系统分区

U盘启动进入Live桌面后打开终端，先查看磁盘分区结构：

bash复制lsblk -f

lsblk -f列出设备的同时会显示文件系统类型和UUID，方便判断哪些是根分区、哪些是EFI分区、哪些是数据分区。常见结构里，根分区可能是/dev/sda2或/dev/nvme0n1p2之类，文件系统通常是ext4或xfs。

以一个常见的/dev/sda2根分区为例：

bash复制mkdir -p /mnt/sysroot
mount /dev/sda2 /mnt/sysroot

如果系统使用了LVM逻辑卷，lsblk会看到klx-root这样的卷组名称，需要先激活卷组：

bash复制vgchange -ay

激活后逻辑卷会出现在/dev/mapper/下，再挂载对应的根卷。假设根卷是/dev/mapper/klx-root：

bash复制mount /dev/mapper/klx-root /mnt/sysroot

如果整个磁盘做了LUKS加密，lsblk显示的分区类型是crypto_LUKS，需要先打开加密卷：

bash复制cryptsetup luksOpen /dev/sda2 myroot
vgchange -ay

打开过程会要求输入LUKS加密口令，这个口令通常在安装系统时设定，和用户登录密码不是一回事。不知道这个口令的话，后续一切操作都无从谈起。

基本根分区挂载好后，为了能让chroot环境正常工作，把设备目录、proc、sysfs、devpts挂载进去。虽然不是所有情况下都必要，但习惯性执行一遍可以在后续操作中避免很多奇怪问题：

bash复制mount --bind /dev /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys /mnt/sysroot/sys

如果有独立的/boot或/boot/efi分区，也把它挂到对应的/mnt/sysroot/boot和/mnt/sysroot/boot/efi路径。这一步对于后面可能需要更新引导配置时很有用。

4.3 chroot进入原系统执行密码修改

挂载完成后，进入原系统环境：

bash复制chroot /mnt/sysroot /bin/bash

执行之后就相当于进到了原系统的根目录中，直接修改密码：

bash复制passwd root

如果是修改普通用户，执行passwd 用户名。新旧密码输入规则和单用户模式相同。修改完成后，同样建议执行：

bash复制touch /.autorelabel

这一步是为了配合启用了SELinux的系统。如果原系统启用了SELinux且处于Enforcing模式，通过LiveCD直接写入的新密码文件在SELinux上下文中可能标记异常，不执行自动重标会导致重启后系统能起来但登录阶段被SELinux拒绝。touch /.autorelabel会让系统在下次启动时对全盘文件做一次SELinux标签重标，重启后正常登录。

随后退出并卸载：

bash复制exit
umount -R /mnt/sysroot
reboot

重启前记得拔掉LiveCD的U盘，然后从原系统盘启动。

4.4 如果盘中数据很重要，挂载前先备份

顺手多说一句：如果这台机器里的业务数据很关键，而且自己对分区结构不熟悉，在执行挂载和修改密码操作之前，最好先备份关键数据。哪怕只是把/etc、/home、/var/lib等目录拷贝到外置存储，也比在分区误操作之后面对无法恢复的局面强得多。处理密码问题时多做的这一小步，很多时候能避免一次运维事故。

5. 服务器版和统一认证环境：改本地密码不一定会生效

单用户模式和LiveCD代表了两种最通用的处理路径，但在生产环境的服务器上，还有几个额外变量会导致方法失效。这里单独拿出来说，是因为“改完密码还是登不上”这类问题里，有很大一部分就出在这些变量上。

5.1 服务器版默认策略与桌面版的现实区别

V10服务器版和桌面版在认证策略上并不一样。服务器版默认情况下大概率不允许root直接SSH登录，它要求先用普通用户登录，再通过su -切换到root。这就意味着业务运维人员在远程忘掉普通用户密码后，完全没有入口执行任何命令，只能去机房接显示器和键盘，或者走服务器的带外管理控制台。

另外，服务器版如果配置了高强度的账户锁定策略，连续输错几次后同样会触发锁定。而且这个锁定发生在PAM层，不仅影响SSH登录，还会影响控制台登录。有些系统甚至对root账户也会启用faillock锁定，部分运维人员以为root不会锁，结果在机房一遍遍尝试，把root账户也锁在了门外。

5.2 接入了LDAP/AD域控后的坑

最容易被忽略的是系统接入了统一身份认证。当V10服务器加入AD域或通过SSSD/LDAP做统一账号管理时，本地/etc/passwd里的账户只是一个“壳”，真正认证由远程服务器完成。这时哪怕你用单用户模式把本地root密码改了，重启后使用域账号登录，依然走的是远程认证，本地的修改根本不会生效。

如何判断有没有接统一认证？如果现场还能找到一台没被锁的机器或能通过其他方式登录，执行：

bash复制getent passwd 用户名

查看返回结果中用户信息来自哪里。如果用户名对应的条目在/etc/passwd中查不到，或者查到了但认证来源指向sssd/ldap，说明这台机器是统一认证客户端。这种情况下正确的操作是去认证服务器上重置对应账号的密码，而不是在原系统上折腾。

还有一种容易混淆的情况：机器里确实有本地root账户，也可以登录，但你在单用户模式里修改的是本地root密码，普通用户本身来自域控。此时无论怎么改本地密码，普通用户登录时依旧提示密码错误。这也是“改了密码依然无法登录”的常见原因之一。

5.3 SELinux、AppArmor等安全模块的额外拦截

部分V10版本会默认启用SELinux，并且装在服务器版上时处于Enforcing模式。如果你通过单用户模式或LiveCD修改密码后没有执行touch /.autorelabel，重启后很可能遇到各种“认证成功但无法进入桌面/SELinux拦截”的问题。

紧急处理时可以临时在GRUB启动参数中加入enforcing=0来绕过SELinux限制，先进入系统确认密码是否修改成功，但生产环境不要依赖这个参数长期运行。正确的收尾方式还是让系统在重启时完成一次SELinux标签自动重标，然后再正常启用SELinux运行。

AppArmor主要在桌面版和部分特定应用层生效，单用户模式修改密码受其直接影响的概率低，但排查问题时要能想到系统里存在这层安全机制。

5.4 远程机器忘记所有凭据时能做什么

如果一台远程服务器所有本地账户密码都失效，SSH又禁止root登录，实际上已经不存在“远程下发命令”的通道了。此时能做的只有通过虚拟化平台的控制台窗口、云主机的VNC/控制台、或物理服务器带外管理卡提供的远程KVM功能进入系统，再走单用户模式或LiveCD方案。

我处理过不少“远程折腾半天最后才去机房”的案例。对于生产服务器，建议运维团队提前把带外管理或虚拟化平台控制台的访问方式记录在案，否则忘记root密码这件事会变得无比被动。

6. 改完密码不验证就交差？后面这几步才是关键

密码重置完成后，很多人会直接重启系统，认为大功告成。实际上有一段最容易翻车的收尾环节：账户锁定计数是否清干净、密钥环是否同步、原有用户策略是否符合预期。这几步没处理好，重启后看到的可能还是“登录失败”。

6.1 重启后的第一次登录，先从TTY终端验证

拿到一个刚修复的V10系统，我最先做的事情不是交给用户，而是自己先在本地控制台按Ctrl+Alt+F2（部分版本是F3/F4）切到字符终端，使用新密码登录一次。

为什么要用字符终端而不是图形界面验证？因为图形登录界面涉及的组件更多，一旦GNOME、钥匙环或显示管理器有问题，界面上的报错容易误导判断。TTY能登录就说明PAM认证、密码哈希、账户锁定都正常了，再切回图形界面去处理剩下的问题会更有针对性。

验证登录成功后执行：

bash复制faillock --user 用户名 --reset

哪怕之前的锁定记录可能因为重启已经清零，这条命令也存在意义——它能确保你离开现场后，用户不会被之前积累的错误计数再次卡住。

同时可以看下最近的认证日志：

bash复制journalctl -b -1 | grep -i "fail\|locked"

这里能直观看到上一次启动过程中哪些认证环节报过错，很多隐藏问题会在这个时候暴露出来。

6.2 桌面版用户会遇到GNOME钥匙环问题

桌面版用户重置密码后，重启进入图形桌面，有可能会不断弹出窗口要求输入密码来解锁登录钥匙环。这是因为GNOME Keyring里保存的认证信息和旧的用户密码绑定，重置密码后系统不知道该用什么密钥去解密已经存在的钥匙环。

处理方式是：在确认用户已经不需要旧钥匙环里的历史条目后，清理当前用户的钥匙环目录：

bash复制rm -rf ~/.local/share/keyrings/*

重新登录后，GNOME会引导创建新的默认钥匙环，新密码就能正常关联。以后连接WiFi、保存浏览器密码时不会再反复弹窗。如果直接删除钥匙环对用户影响较大，也可以尝试在图形界面里输入旧密码来解锁钥匙环，但旧密码往往记不清，所以现实操作中大多数时候还是删掉重建更利落。

6.3 按照系统密码策略确认复杂度和到期规则

V10的密码复杂度策略主要靠pam_pwquality管理。root用户通过单用户模式或LiveCD直接执行passwd时，通常不受复杂度限制；但普通用户登录后执行passwd修改自己的密码，会受复杂度策略约束，需要包含大小写字母、数字甚至特殊字符，长度也有限制。如果重置时设置的密码太简单，系统可能即使在安静模式下列为“BAD PASSWORD”，却因为是在重置流程中直接写入而“看上去成功”了，等用户真正想通过策略改密时反而会被拒。

建议顺手检查一下目标账户的状态：

bash复制chage -l 用户名

如果需要让用户下次登录时必须改密码，可以设置：

bash复制chage -d 0 用户名

这样用户下次登录会收到密码过期提示，强制设置一个新的自己记得住的密码。这个操作非常适合“临时帮用户重置密码”的场景——你暂时用复杂的新密码进入系统，然后把改密义务交还给用户本人，符合安全习惯。

6.4 恢复系统的“干净”状态

如果是临时为了救急在GRUB或LiveCD中添加了一些特殊参数，比如enforcing=0、rd.break，重启恢复后需要确保这些参数的修改没有永久写入GRUB配置。编辑GRUB菜单只是临时的启动时修改，重启后自然消失，正常启动不会受影响。

如果在单用户模式下执行过touch /.autorelabel，系统会自动进行一次文件标签重标，整个过程可能持续几分钟。耐心等待它完成，不要中途强制断电，否则下次启动可能依旧存在SELinux上下文异常问题。

最后，别急着把机器直接还给使用者。花两分钟用重置后的密码在桌面环境完整登录一次，打开文件管理器、试一下用户名和密码相关的功能，确认无异常后再交接。毕竟系统是给别人用的，万一交接时没问题、第二天用户正常锁屏后却记错了新密码，那就又变成一次循环求助了。

我在处理这类问题时最深的体会是：密码重置本身并不复杂，真正的难点在于每个人遇到的具体系统环境都不一样，多一个PAM策略、多一个SELinux标签、多一个域控接入，处理路径就可能完全不同。分清场景、判断状态、再做操作，才是这个问题的真正解法。上面这些路径和坑是我实际踩过之后总结出来的，希望能帮你少走一圈弯路。