三年前我接过一台别人移交的 CentOS 7 测试机交接单上写的 root 密码怎么试都不对SSH 一直回 Login incorrect。当时我心想这不是小菜一碟rd.break走一遍就完事了。结果那台机器我前前后后折腾了两个多小时密码改了四遍才真正登进去——中间踩到的坑从/sysroot忘了重新挂载到 SELinux 上下文丢失再到/etc/shadow被安全加固脚本加了 immutable 属性一个都没落下。CentOS 7 重设密码这件事网上的教程一搜一大把步骤看着也就五六行命令但真正动手的时候失败率出奇地高。原因在于这些教程只写了顺风局的走法一旦中间任何一环出问题它们都不会告诉你下一步该往哪查。这篇内容就是把这五六行命令背后每一环可能断掉的地方拆开讲清楚包括怎么判断断在哪一环、每一步为什么必须那样做、以及那些教程里从来不写的边界情况。适合已经会基本 Linux 操作、但在实际重设密码时被卡住的运维和开发同学也适合刚开始接触系统救援的新手照着排查。1. 先把重设失败分成三种别一上来就敲 rd.break新手最典型的做法是密码登不上立刻重启进 GRUB敲一遍rd.break那套命令重启还是登不上然后开始怀疑人生把同样的步骤再重复一遍。重复三次之后时间就过去一小时了问题一次都没被缩小过范围。真正高效的做法是先花三十秒判断自己面对的是哪一类失败因为三类失败的排查路径完全不同混在一起查只会互相干扰。1.1 三种失败现场改不了、改不动、改了没用第一类是改不了表现是你连操作入口都没拿到。GRUB 菜单倒计时结束得太快你根本没来得及按键或者菜单出来了但你按e之后提示要输入用户名密码那是grub.cfg里配置了 superusers再或者你的机器是云上的实例控制台只给你一个 VNC 画面键盘事件根本传不进去。这类问题的核心不在于密码本身而在于你要换一条进入系统的路径。第二类是改不动表现是你已经成功进入了那个switch_root:/#或者救援 shell但passwd root命令直接报错退出。常见的报错有passwd: Authentication token manipulation error、Read-only file system、Operation not permitted、passwd: User not known to the underlying authentication module。这类问题的核心是文件系统状态、文件属性或者 PAM 配置挡住了写入。第三类是改了没用表现最迷惑人passwd命令提示两次输入新密码最后打印passwd: all authentication tokens updated successfully你满心欢喜重启登录界面照样告诉你密码错误。这类问题几乎都跟 SELinux 上下文、账户锁定状态、或者你根本改错了系统比如 LVM 卷没挂对你 chroot 进了另一个根有关。我自己遇到那台机器就同时踩了第二类和第三类第一次是/sysroot只读导致passwd失败第二次是权限属性拦路第三次命令成功了但重启登不上最后才发现是 SELinux 标签的问题。1.2 一次密码重设要跨过的六个环节把整个过程拆成一条链你会发现失败点其实很好定位环节该环节要做的事典型断点GRUB 编辑在内核行尾追加rd.break改错行、菜单被密码锁、按键传不进控制台initramfs shell拿到switch_root:/#提示符参数拼写错误、进了老的init/bin/bash路径重新挂载mount -o remount,rw /sysroot忘了这步后面全部只读失败chroot切入真实根文件系统挂载点不对、LVM 没激活改密码执行passwd或直接写哈希只读、immutable 属性、PAM 策略拦截收尾与重启处理 SELinux 标签后重启漏掉 relabel重启后依然登不上这张表建议你直接记在脑子里。每次失败时先回答一个问题我是在第几环断的只要能把断点定位到具体某一环剩下的就是查这一环的手册而不是盲目重试。提示等你把这条链走顺了会发现真正花时间的不是操作而是判断。命令本身加起来不到一分钟。2. rd.break 里那几行命令顺序错了就白改CentOS 7 和 CentOS 6 在系统初始化上换了一代CentOS 6 时代流行的那套写法拿到 7 上直接用成功率很低。这是很多人失败的第一层原因而教程往往不会提醒你版本差异。2.1 GRUB 菜单里该动的是 linux16 还是 linuxefi重启后要抓住 GRUB 菜单这一步在虚拟机上一般不难但有几个细节容易翻车。如果菜单一闪而过可以在启动时按住方向键或者 Esc 让倒计时停下物理机 BIOS 引导按 EscUEFI 引导按 Esc 或者方向键都行。云主机的远程控制台有时会吞按键这种情况多按几次或者在实例控制台里先点一下画面让焦点进去再按方向键。进到编辑界面后你会看到类似这样的行linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root/dev/mapper/centos-root ro crashkernelauto ... initrd16 /initramfs-3.10.0-1160.el7.x86_64.imgBIOS 引导的机器用linux16开头的行UEFI 引导的机器是linuxefi。要动的是这个内核行initrd16那行不用碰。把光标移到该行末尾一般是rhgb quiet之后空一格加上rd.break。想顺手把 SELinux 临时关掉便于诊断可以写成rd.break enforcing0。这里有个我自己踩过的坑很多人照着 CentOS 6 的教程改写的是init/bin/bash或者把ro改成rw init/bin/bash。在 CentOS 7 上这条路能进去但系统是被 systemd 管理的/dev、/proc这些虚拟文件系统没有按正常流程挂载很多命令会莫名其妙地缺依赖。更麻烦的是用这种方式改完的文件在标签处理上更容易出问题重启后密码改了但登不上的概率明显更高。几种进入方式的差别我整理成了表方式内核行添加内容适合场景主要坑点rd.break行尾加rd.breakCentOS 7 首选必须手动 remount 和 chrootinit/bin/bashrw init/bin/bash老版本系统习惯虚拟文件系统未挂载标签易异常systemd.unitrescue.target行尾追加该参数你还记得 root 密码时会要求输入 root 密码才能进安装镜像救援模式从 ISO 引导GRUB 被锁或损坏需要能挂载启动介质2.2 remount,rw 和 chroot 的先后关系不能颠倒按下 CtrlX 之后系统会停在一个switch_root:/#的提示符上。这时候你面对的是一个内存里的临时根环境真实的根文件系统已经被挂载到/sysroot但是是只读挂载的。很多人到这里直接chroot /sysroot然后passwd结果就撞上Read-only file system。正确顺序是mount -o remount,rw /sysroot chroot /sysroot passwd root第一条命令把/sysroot从只读改成可读写。第二条命令把当前进程的根切换到真实系统这样你执行passwd时读写的才是真实的/etc/shadow而不是 initramfs 里的临时文件。这个先后关系不能反也不能省——chroot之后再mount -o remount,rw /是另一种写法效果类似但前者更直观。怎么确认自己挂对了在 chroot 之前敲一条mount | grep sysroot应该能看到/dev/mapper/centos-root on /sysroot type xfs (ro,relatime...)执行 remount 之后ro会变成rw。如果这条命令显示的设备名跟你预期的不一样比如根分区其实在别的卷上那就说明你后面的所有操作都会作用在错误的文件系统上这是改了没用的一类隐藏原因。2.3 Authentication token manipulation error 到底在抱怨什么这个报错是重设密码场景里出现频率最高的一个但它的措辞非常含糊几乎不告诉你任何有用信息。它的字面意思是认证令牌操作出错翻译成人话就是passwd尝试更新/etc/shadow里的密码字段失败了。至于为什么失败要看上下文。我把常见的几种根因列一下方便你按顺序排除可能原因判断方法处理方式根文件系统仍是只读mount | grep sysroot显示 ro重新执行 remount/etc/shadow有 immutable 属性lsattr /etc/shadow有 i 标记chattr -i /etc/shadow/etc/shadow权限异常ls -l /etc/shadow不是 000 或 0000chmod 000 /etc/shadowpasswd 与 shadow 条目不匹配grep root /etc/passwd与grep root /etc/shadow对比手工补齐缺失条目磁盘或 inode 写满df -h、df -i清理空间nsswitch 配置被改坏cat /etc/nsswitch.conf看 passwd 行恢复为files其中权限这一项容易被忽略。/etc/shadow的标准权限是0000或者说----------也就是属主 root 自己也只能通过passwd这类 setuid 程序访问普通读取会被拒绝。如果被某个脚本改成了644某些较真的系统会拒绝更新它。3. 重启后依旧 Login incorrectSELinux 上下文是最隐蔽的元凶这一类失败最折磨人因为你的所有操作都显示成功了passwd也给了明确的成功提示重启之后系统看起来一切正常SSH 端口在监听日志里却只有一句轻飘飘的Failed password。你会本能地怀疑是不是自己记错了密码然后开始怀疑键盘、怀疑输入法、怀疑 CapsLock最后把密码又改了一遍问题依旧。3.1 用 ls -Z 一眼看出 /etc/shadow 的标签是否正常CentOS 7 默认开着 SELinux处于 enforcing 模式。每个文件身上都挂着一个扩展属性security.selinux记录它的安全上下文。/etc/shadow必须带上shadow_t这个类型登录程序才能读到它。正常状态下ls -Z /etc/shadow # -rw-------. root root system_u:object_r:shadow_t:s0 /etc/shadow如果你在rd.break环境下用passwd改了密码可能出现的后果是/etc/shadow的上下文变成了unlabeled_t或者是admin_home_t、etc_t这类不对的类型。这时候sshd试图读取它就会被 SELinux 拒绝认证自然失败。而由于拒绝发生在读取阶段日志里往往看不到密码错误以外的线索。为什么在救援环境改文件会把标签搞坏核心原因是 initramfs 里 SELinux 策略根本没加载系统处于一种标签机制不生效的状态文件被重写时无法正确维护扩展属性。这也是为什么官方文档在rd.break流程里反复强调要触发一次 relabel。如果在正常系统里确认可以先看 AVC 拒绝记录ausearch -m avc -ts today | grep shadow有输出基本就实锤了。3.2 /.autorelabel 触发的全盘重标记到底要等多久标准的收尾动作是在 chroot 环境里、退出之前执行touch /.autorelabel注意此时你还在 chroot 里/就是真实系统的根所以这个文件会创建在真实根分区上。下次启动时 systemd 会检测到它触发一次完整的 relabel把整个文件系统上所有文件的标签按策略重新打一遍。打完标签后这个文件会被自动删除。新手在这里最常见的误会是机器卡死了。全盘 relabel 会扫过每一个 inode磁盘越大越慢几十 GB 的机器可能跑十几分钟几百 GB 的跑一两个小时都不奇怪机械盘更慢。判断它是不是在正常工作可以切到另一个 tty 或者看磁盘灯正常情况下setfiles进程会占满一个 CPU 核心磁盘持续有读写。这一点请不要急着按电源键中途断电有可能让文件系统处于半标记状态虽然不致命但会让下次排查更混乱。注意如果你是在一个容量很大的数据盘根分区上做这个操作先掂量一下时间成本。有时候换个思路直接修标签比等两小时更划算。3.3 不想等 relabel 的替代路径enforcing0 配合 restorecon如果时间紧或者你只是改了/etc/shadow一个文件没必要全盘重标记。可以这样走在 GRUB 内核行末尾加上rd.break enforcing0这样系统起来之后 SELinux 处于 permissive 模式不会拦截任何操作。登录进去之后立刻做两件事restorecon -v /etc/shadow /etc/passwd /etc/group /etc/gshadow然后确认getenforce显示的是Permissive再把它切回强制模式setenforce 1最后重新登录验证一次。如果切回 enforcing 之后依然能正常登录说明标签已经修好了如果一变回 enforcing 就又登不上那说明还有别的文件标签不对老老实实做一次全盘 relabel 更省事。还要提醒一点enforcing0是临时参数重启就失效不会写进配置文件。但如果你顺手在/etc/selinux/config里把SELINUX改成了permissive而忘了改回来那就是永久削弱了防护这个坑很多人踩过改完密码之后一定要回头检查这个文件。4. passwd 命令当场就报错时先查这几个硬化痕迹前面说的都是操作成功但结果不对这一类则是操作当场就被拒绝。这类问题的排查其实是三类里最直接的因为系统给了你明确的报错只要知道每个报错对应什么原因就行。4.1 /etc/shadow 上的 immutable 属性很多做过安全加固的机器会按基线要求给关键账户文件加上不可变属性防止被恶意程序篡改。这个属性对正常的passwd命令是致命的因为它根本不允许任何人写这个文件连 root 也不行。表现就是passwd直接报Authentication token manipulation error或者Operation not permitted非常符合我明明挂成 rw 了为什么还是写不进去的困惑。检查和处理lsattr /etc/shadow /etc/passwd /etc/group /etc/gshadow chattr -i /etc/shadowlsattr输出里如果第二列有i说明加锁了。改完密码之后如果企业基线要求必须保持这个属性记得用chattr i /etc/shadow加回去否则下次安全扫描会报不合规。这个改完记得还原的动作是加固环境下的必修课我见过不止一次有人改完密码忘了加回属性第二天被巡检脚本告警。4.2 密码复杂度策略把新密码挡在门外PAM 的pam_pwquality模块会对新密码做强度的校验。别以为 root 改自己的密码就能随便设在 RHEL 7 / CentOS 7 上即使是 rootpasswd也会走一遍密码质量检查。如果你的新密码太短、纯数字、包含用户名或者命中字典词就会看到BAD PASSWORD: The password is shorter than 8 characters BAD PASSWORD: The password fails the dictionary check这时候有两个方向一是老老实实设一个符合策略的密码比如十二位以上、大小写加数字加符号二是临时放宽策略。临时放宽可以编辑/etc/security/pwquality.conf把minlen改成 1、minclass改成 0改完密码之后务必改回来。但在救援环境下改配置文件本身也有风险我更推荐下一种做法。4.3 绕开 PAM 直接写哈希的三种写法如果你只想要一个能登进去的密码完全不需要经过passwd。/etc/shadow第二个字段就是一个密码哈希你自己算一个填进去就行这条路不经过任何 PAM 检查速度最快也最不容易被打断。先算哈希CentOS 7 默认用 SHA-512openssl passwd -6 # 交互式输入密码输出类似 $6$xxxxxxx$yyyyyyyyyyyy也可以用 PythonCentOS 7 自带 Python 2.7crypt 模块可用python -c import crypt; print(crypt.crypt(YourNewPass, crypt.mksalt(crypt.METHOD_SHA512)))或者用 Perlperl -e print crypt(YourNewPass, \$6\$salt\$), \n拿到$6$...开头的哈希之后用usermod写进去usermod -p $6$xxxxxxx$yyyyyyyyyyyy rootusermod -p直接把哈希塞进 shadow不走密码验证逻辑也就不会触发任何复杂度策略。提示哈希里含$符号在 shell 里必须用单引号包起来。用双引号会被 shell 当成变量展开最后写进去的哈希是残缺的然后你会面对一个更迷惑的现象——命令成功但密码永远不对。还有一种原始但可靠的办法直接编辑/etc/shadow把 root 那一行第二个冒号之间的内容替换成新哈希。注意这一行是用冒号分隔的别改错字段。用vi打开找到root:开头的那行只替换第二段。这个方式在极端环境下usermod因为某些依赖缺失跑不起来是最后的兜底。5. 单用户模式压根进不去救援模式与手工挂载 LVM前面所有方案都建立在一个前提上你能编辑 GRUB 内核行。但如果这个前提不成立就得换一条路。5.1 GRUB 被 superusers 锁住之后还剩哪些入口打开/boot/grub2/grub.cfg如果看到类似这样的配置说明 GRUB 菜单被密码保护了set superusersadmin password_pbkdf2 admin grub.pbkdf2.sha512.xxxxx...这种情况下按e会先要你输入用户名和密码输不对就没法进入编辑界面。想绕过有很多路径最正统的是从安装介质引导进入救援模式如果有物理接触条件进 BIOS 把光盘或者 U 盘设为第一启动项如果是虚拟机把 ISO 挂到虚拟光驱上再重启如果你还有另一条能登录的路径比如普通用户也可以从系统内部想办法但那通常需要 sudo 权限。我要强调的是GRUB 密码是为了防止物理接触者改内核参数所以绕过它的方法本质上都是物理接触 另一个启动介质。这条路径在设计上就留好了不用去找什么奇怪的技巧。5.2 CentOS 7 安装镜像的救援模式操作路径准备好对应版本的 CentOS 7 安装 ISO挂载启动在引导菜单里选Troubleshooting进去之后选Rescue a CentOS Linux system。系统会扫描硬盘上的安装找到之后给你几个选项选1) Continue让它把系统挂载到/mnt/sysimage。挂载完成之后它会提示你执行chroot /mnt/sysimage这样你就进入了真实系统。之后的passwd root操作和在正常系统里完全一样也没有只读挂载的问题因为救援模式本身就把文件系统挂成可写了。救援模式还有个好处它会自动激活 LVM自动识别根分区。对于不熟悉 LVM 的同学来说这条路径比手搓挂载命令省心得多。改完密码之后同样别忘了处理 SELinux 标签最简单的方式就是touch /.autorelabel然后exit退出 chrootreboot重启。5.3 手工激活 LVM 并挂载根分区的完整命令序列有些场景下救援模式也进不去比如没有光驱、没有可用的 ISO或者系统用的是 LVM 需要你在一个通用的 Live 环境里手工挂载。这时候命令序列要写对vgscan vgchange -ay lvs前两条是扫描卷组并激活它lvs用来确认逻辑卷的名字通常根卷叫centos-root交换卷叫centos-swap。确认之后挂载mkdir -p /mnt/sysroot mount /dev/mapper/centos-root /mnt/sysroot mount /dev/sda1 /mnt/sysroot/boot如果你的机器是 EFI 引导还要补一条挂载 EFI 分区。之后为了在 chroot 里用passwd之类需要访问设备的命令最好把虚拟文件系统也挂进去mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys chroot /mnt/sysroot这里有个判断技巧特别实用进 chroot 之后敲一下cat /etc/redhat-release看看版本号是不是你要修的那台机器。如果输出的是 Live 环境自己的版本说明挂载点错了你正在改的是一个临时系统的文件改一百遍也没用。这个错我犯过一次当时在一个有多块盘的服务器上挂错了卷折腾半天才反应过来。另外如果根分区在挂载时报文件系统错误先别急着xfs_repair因为它有破坏性。先跑只读检查xfs_repair -n /dev/mapper/centos-root确认有问题再卸掉挂载之后正式修。修完再挂回来继续。6. 密码确认正确却依然登不进去的几种情况这一节说的是密码本身没问题、SELinux 标签也没问题、但登录依然失败的情形。这类问题的特点是你换一个普通用户登录是正常的只有 root 不行或者反过来。6.1 账户被锁、被 faillock 拦、shell 被改成 nologin先看账户状态passwd -S root输出格式是root PS 2024-01-01 0 99999 7 -1这样一串。第二个字段最关键PS表示密码已设置且可用LK表示账户被锁定NP表示没有密码。如果是LK用这个解锁usermod -U root再看 shell。有些加固脚本会把 root 的登录 shell 改成/sbin/nologin或者/bin/false这样即使密码完全正确SSH 也不会给你 shell。检查一下grep ^root: /etc/passwd最后一列如果显示/sbin/nologin改回/bin/bash就行。用usermod -s /bin/bash root或者直接编辑/etc/passwd。还有两种情况经常被忽略。一是密码有效期CentOS 7 默认 root 的密码通常不过期但如果有人手工设过chage密码过期后即使输对了也会被要求先改密码而如果是一个不能交互的登录方式就会直接失败。用chage -l root看一下过期时间。二是pam_faillock记录如果你刚才连续输错很多次密码账户可能被临时锁了一段时间。查看和重置faillock --user root faillock --user root --resetfaillock的输出里V那一列是有效失败次数达到阈值就会触发锁定。这个机制在排查时非常容易让人误判因为你改完密码就急着试试三次失败又被锁了看起来像密码改了没用。6.2 控制台键盘布局导致的我明明输对了这个坑在虚拟机控制台和物理机前特别常见。rd.break环境下键盘布局用的是 initramfs 里内建的默认布局通常是 US。如果你的物理键盘是德语、法语或者其他布局那些、、/、y、z之类的键位位置是不一样的。你在屏幕上敲的是你以为的密码系统收到的是另一串字符。判断方法很简单故意设一个只用字母和数字、并且避开y和z的密码如果能登进去那就是布局问题。解决思路是先用一个简单密码进去登录之后再改成复杂密码那时候系统完整加载布局也对了。还有几个纯输入层面的小问题也值得提一句远程控制台粘贴密码时可能吞掉或者多出换行虚拟机的 NumLock 状态和你主机不一致导致小键盘输入变成方向键有的 KVM 控制台对组合键支持有问题。这些都属于操作层面的问题排查时不要往系统配置方向想。6.3 改完之后必须跑一遍的验证清单我把每次改完密码后自己会跑的检查列出来大概十几秒就能过一遍能过滤掉大部分低级错误getent shadow root # 确认 shadow 里有 root 且 hash 非空非 ! 非 * passwd -S root # 确认状态是 PS 而不是 LK ls -l /etc/shadow # 确认权限是 000 或 0000 ls -Z /etc/shadow # 确认标签是 shadow_t grep ^root: /etc/passwd # 确认 shell 是 /bin/bash chage -l root # 确认密码未过期 systemctl status sshd # 确认服务正常 ss -tnlp | grep :22 # 确认端口在监听getent shadow root那条特别有用它会输出 shadow 文件的完整条目。第二段如果是!!或者*说明这个账户根本没有可用密码如果是以!开头说明账户被锁但底层有密码。看懂这一行很多问题就一眼明了。7. 顺带聊聊常和这个故障一起出现的两个重设场景在同一个环境里CentOS 系统的 root 密码、MySQL 的 root 密码、phpMyAdmin 的登录密码经常是一起被遗忘的因为很多人就是一台机器上跑着一整套东西很久不管就全忘了。这几个重设的底层逻辑其实很像都是绕过认证层直接改存储认证凭据的文件。7.1 MySQL 5.7 的 root 密码与 authentication_stringMySQL 5.7 里用户密码存储的字段从Password换成了authentication_string很多老教程还在写UPDATE mysql.user SET PasswordPASSWORD(xxx)在 5.7 上会直接报字段不存在。正确的做法是systemctl stop mysqld mysqld_safe --skip-grant-tables --skip-networking mysql -uroot进去之后USE mysql; UPDATE user SET authentication_stringPASSWORD(NewPass) WHERE userroot; FLUSH PRIVILEGES;注意--skip-networking这个参数很重要它让数据库在跳过权限检查的这段时间不监听网络端口避免有外部连接趁虚而入。改完之后退出杀掉 mysqld_safe 进程再正常启动服务。这里和系统密码重设有点像的地方是FLUSH PRIVILEGES相当于让内存里的权限表重新加载如果不刷改了也不生效。这一步漏掉的人不少。7.2 phpMyAdmin 的认证方式决定了要不要同步改配置文件phpMyAdmin 的config.inc.php里有一个关键配置$cfg[Servers][$i][auth_type] cookie;如果这里是cookie用户每次通过登录页输入账号密码你改了数据库密码之后不用动配置文件。如果是config意味着数据库的用户名和密码是硬编码在配置文件里的$cfg[Servers][$i][user] root; $cfg[Servers][$i][password] OldPass;这种情况下你只改了数据库密码phpMyAdmin 自己反而连不上了页面会报无法连接设置无效之类的错误。排查时优先看这个配置项别一头扎进数据库权限表里查半天。还有$cfg[Servers][$i][AllowNoPassword]这个开关如果是 true 并且密码被清空过会有安全问题建议保持 false。7.3 离线机器上修复被改坏的 PAM 需要先用本地源最后回到 CentOS 7 本身。如果前面的排查都排除了你怀疑是 PAM 配置被某个加固脚本或者误操作改坏了可以用包管理器重装一遍相关包把配置恢复到默认状态。但内网机器往往连不上外网源这时候需要先搭一个本地源mkdir -p /mnt/iso mount -o loop /root/CentOS-7-x86_64-DVD-2009.iso /mnt/iso然后写一个 repo 文件指向它[local] nameCentOS 7 Local baseurlfile:///mnt/iso gpgcheck0 enabled1保存到/etc/yum.repos.d/local.repo。之后先看哪些包被动过rpm -V pam rpm -V opensslrpm -V会列出被修改过的文件如果/etc/pam.d/system-auth出现在列表里说明它被改过。重装yum reinstall pam重装不会覆盖你标记为%config(noreplace)的文件所以如果配置文件确实被改坏可能需要先备份再手动恢复或者从同一版本的干净系统上拷一份过来。顺手说一句搭好这个本地源之后离线安装 docker 也就顺理成章了——把 docker 的 rpm 包及其依赖放进同一个目录或者再挂一个 docker 的本地仓库yum install docker-ce就能直接跑通。我自己在重设密码这件事上总结下来最有价值的一条经验是不要把它当成一个按步骤操作的任务而要当成一次故障定位的任务。那五六行命令真正的难点从来不在命令本身而在于判断当前失败发生在哪一环。每次动手前先花半分钟问自己我现在是在哪一环遇到阻碍然后只针对这一环查资料比把整篇教程重头再念一遍有效率得多。还有一点改完之后立刻跑一遍验证清单别急着重启很多时候问题在重启前就能被这几条命令抓出来。