★ FEATURED ARTICLE 1. 修改密码前的底层认知与整体思路1.1 密码到底存在哪里验证链路是怎样的很多刚接触Linux运维的朋友第一次接到“修改root密码”这个任务时脑子里冒出来的想法是登录进去执行passwd输入两遍新密码完事。确实这是最常见的路径但如果你想在真实环境里不出岔子——尤其是面对生产服务器、客户系统、云主机时——还是得先把底层的密码存储和验证机制搞清楚。Linux系统的账号密码信息主要存放在两个文件里/etc/passwd和/etc/shadow。/etc/passwd是全局可读的里面保存了用户名、UID、GID、家目录、登录Shell等信息。密码哈希字段在现代系统上不会放在/etc/passwd里而是放在只有root用户或特定权限组才能读取的/etc/shadow文件中。这也是为什么普通用户能查询自己的账号信息却不能随便看到其他人的密码哈希。/etc/shadow里每一行大致是这样root:$6$saltsalt$hashhashhash:19000:0:99999:7:::字段用冒号分隔依次是用户名、密码哈希、最后一次修改密码的日期、最短修改间隔、最长有效期、警告天数、宽限天数、失效日期和保留字段。密码哈希前面的$6$表示SHA-512算法$y$是yescrypt$2b$是bcrypt不同发行版默认算法不一样。CentOS 7 时代常见$6$较新版本系统则开始转向$y$。了解这些算法的意义在于当你用passwd命令修改密码时系统会根据/etc/login.defs和 PAM 配置选择对应的哈希算法这个选择通常不需要你手动干预但如果你在写脚本调用某些底层的库函数就必须注意算法兼容性。验证链路也不复杂用户登录时输入密码系统根据用户名读取/etc/shadow中对应记录的哈希用相同的salt对输入的密码做哈希再将结果与存储的哈希比对一致即通过。整个过程由 PAM可插拔认证模块统一调度passwd只是前端工具真正做事的是pam_unix.so这类模块。理解这一点你才能在遇到“明明密码改成功了SSH却登录不了”这种诡异问题时想到去检查 PAM 配置而不是傻乎乎地再改一遍。1.2 密码安全策略决定了你的修改方式修改密码不是瞎改安全策略才是背后真正的主导逻辑。常见的策略要求包括密码最小长度、复杂度包含大写、小写、数字、特殊字符、定期更换周期、防止使用最近使用过的密码历史。这些策略在/etc/login.defs和/etc/security/pwquality.conf里定义。运维人员在执行密码修改时需要提前确认系统当前启用的密码复杂度规则否则可能遇到passwd提示BAD PASSWORD: it is too simplistic/systematic之类的报错。举例来说/etc/security/pwquality.conf中常见参数有minlen 8 dcredit -1 ucredit -1 lcredit -1 ocredit -1minlen是最小长度dcredit表示至少包含多少个数字负值表示至少要有几个ucredit是大写字母数量lcredit是小写字母数量ocredit是特殊字符数量。如果这些参数被设置得比较严格你试图设置一个简单的短密码就会遭到拒绝。这其实是系统在保护你而不是在为难你。从运维视角看修改密码前应该理清楚三个问题这次修改是主动的安全加固还是因为密码泄露的应急响应或者是账号权限交接如果是应急响应改完密码之后还要检查是否有异常登录记录、是否有恶意计划任务残留如果是权限交接除了改密码还应该考虑把密钥对、双因子认证信息一并更换。密码本身只是账号安全的一部分不该孤立处理。2. 修改root密码从命令行到救援模式的完整路径2.1 三种场景下的root密码修改第一种场景最简单你已经以root身份登录系统或者有一个拥有sudo权限的普通账户。此时修改root密码只需一条命令sudo passwd root执行后系统会提示输入新的root密码并确认。注意这里有个细节如果当前用户本身就是rootpasswd root可以直接执行如果是普通用户使用了sudo则需要输入当前用户的密码来获得提权能力。很多人对sudo passwd root和sudo passwd两个命令搞混前者修改的是root用户的密码后者在默认配置下修改的是当前普通用户自己的密码。后者通常用于普通用户主动修改自己的密码但前提是用户自己知道当前密码。第二种场景只记得普通用户密码不记得root密码但普通用户有sudo权限。这种情况不需要重启系统也不需要进救援模式直接sudo passwd root即可。这提醒我们一个安全要点拥有sudo权限的普通用户实质上就是能改root密码的准管理员。日常运维中不要把sudo权限随便授予不信任的账号。第三种场景连普通用户密码都不记得或者系统只允许root登录但root密码丢失。这种情况必须走救援流程我会在第4章详细展开。这里先给出一个高层面结论只要能接触到物理机或管理控制台Linux系统的root密码就总有办法重置区别只是麻烦程度。2.2 root账号的锁定与解锁除了修改密码root账号还有一个容易被忽略的操作维度锁定与解锁。所谓“锁定”本质上是通过特殊的方式让密码验证永远无法通过常见做法有两种一种是把密码哈希字段设置成不可用的值比如!或*另一种是通过passwd -l命令设置账号锁定状态。对应的解锁命令是passwd -u。查看一个账号当前的状态可以用passwd -S root输出中会显示root L或root P之类的状态L表示锁定P表示可用密码。在新装的Ubuntu系统上root账号默认是锁定状态管理员通过sudo passwd root设置密码时系统会自动解锁。在CentOS/RHEL系统上root默认是可登录的除非安装时显式配置了禁止root SSH登录。这里我给出一个实用建议如果你的服务器暴露在公网上root账号的密码哪怕设置得很复杂也不建议允许root直接通过SSH登录。常规做法是创建一个普通用户并授予sudo权限把SSH的PermitRootLogin设置为no。原因很简单root账号是暴力破解的首要目标禁掉直接登录能大幅减少攻击面。但要注意如果关闭了root SSH登录同时又把唯一有sudo权限的普通用户的密码忘了后果就是你得通过物理控制台走救援流程云服务器就得用网页端的VNC登录折腾不少所以改配置前要有兜底方案。3. 修改普通用户密码从单人到批量3.1 单用户密码修改的正确姿势普通用户修改自己的密码命令很简单passwd系统会先让你输入当前密码验证通过后才允许设置新密码。整个过程不需要root权限但这里的限制是你只能修改自己的密码而且必须先通过旧密码验证。这是Linux系统的一种自我保护机制——即使有人短暂占用了你的终端也无法在没有旧密码的情况下轻易改变你的密码。如果你是管理员需要重置某个普通用户的密码则需要root权限sudo passwd zhangsan执行后系统不会询问旧密码直接设置新密码。这在实际运维中很常见比如员工忘记密码、账号需要临时接管、入职离职交接等。管理员重置密码时不需要知道用户当前的旧密码这也符合安全原则管理员不需要知道用户的旧密码只需要能创建新的凭据。需要注意一个常见误区用sudo passwd zhangsan修改密码后如果该用户当前已登录系统他的现有SSH会话不会被踢出已经建立的密钥登录也不受影响。这意味着如果账号被盗且攻击者已经建立了会话单纯的密码重置并不能立刻切断攻击者。此时还需要配合pkill -u zhangsan切断用户进程甚至进一步检查攻击者是否植入了后门。安全应急时改密码只是第一步不是全部。3.2 批量修改与首次登录强制改密服务器数量一旦变多单条passwd命令就忙不过来了。常见需求是把一批用户密码批量设置为某个统一值或者根据用户列表逐一设置。这时可以用chpasswd命令。Debian/Ubuntu系的标准做法是通过管道给chpasswd输入数据echo zhangsan:NewPass123! | sudo chpasswd这种方式的好处是支持批量处理可以把多行用户名和密码一次性喂进去sudo chpasswd users.txtusers.txt每行格式为用户名:新密码。在RHEL/CentOS系上有人习惯用echo NewPass123! | passwd --stdin zhangsan--stdin表示从标准输入读取密码。这个选项在Debian系的passwd上不支持所以跨发行版时我更推荐chpasswd它的兼容性更好。写脚本时还要注意用命令行直接传密码会把密码暴露在shell历史和进程列表中稳妥的做法是通过read -s从终端交互式读取或把密码文件权限限制为600并在用完立即删除。批量修改之外还有一个高频需求首次登录强制改密。管理员为用户分配初始密码后希望用户第一次登录时必须先修改为自己的秘密。实现方法是在设置初始密码之后把密码的最后修改日期归零sudo chage -d 0 zhangsan这样用户下次登录系统时会被强制要求修改密码修改完成后才能正常使用环境。这里的原理是chage -d 0把lastchg字段设置为0而系统的时间从1970年1月1日算起因此系统认为密码已经过期触发改密流程。这个命令不会影响密码本身的哈希值只是修改了有效期元数据。4. 忘记密码后的救援流程4.1 systemd发行版下的救援模式处理无论什么场景救援模式的基本思想是一致的在操作系统完整启动之前通过内核参数或启动菜单进入一个特权环境重新挂载根文件系统为可写状态然后直接修改/etc/shadow或执行passwd命令。整个过程依赖物理控制台或云平台的远程控制台依赖SSH是行不通的因为SSH服务此时还没起来。以常见的systemd发行版CentOS 7及以上、Ubuntu 15.04及以上、Debian 8及以上为例标准操作流程是重启服务器在GRUB菜单出现时选中默认内核启动项按e键进入编辑模式。找到以linux或linux16开头的那一行在行尾添加一个临时内核参数。CentOS系通常用rd.breakUbuntu/Debian常用systemd.unitrescue.target也有的系统直接写init/bin/bash。按CtrlX或F10启动系统进入带root权限的紧急环境。此时根文件系统往往是只读挂载的。需要手动重新挂载为读写模式才能修改密码文件。下面是CentOS系rd.break的完整处理命令序列mount -o remount,rw /sysroot chroot /sysroot passwd root touch /.autorelabel exit exit这里的细节容易踩坑。rd.break模式下真实根文件系统会被挂载到/sysroot而当前的环境是一个精简的初始内存盘环境。如果不做chroot /sysroot就执行passwd root修改的是救援环境的密码与真正系统无关。touch /.autorelabel是为了在SELinux强制模式下触发文件标签重建如果不做这一步改完密码之后系统可能因为SELinux上下文异常而无法正常登录。这一步很多人会漏掉导致绕了一大圈发现密码还是不对。Ubuntu/Debian系使用systemd.unitrescue.target进入救援模式后系统通常会在一个较完整的环境里提示输入root密码或允许直接提权。如果提示需要root密码但你恰好忘了可能需要改用init/bin/bash这种方式流程类似mount -o remount,rw / passwd root exec /sbin/init4.2 重置后的权限与安全注意事项救援模式下重置密码是最后手段但这里有几个必须注意的地方。第一整个救援过程绕过了正常的认证机制。任何能够物理接触服务器的人都可以通过这种方式重置root密码所以物理安全和控制台访问权限的重要性不亚于系统密码本身。在数据中心托管服务器时机柜的物理访问控制必须管好。第二重置密码后会遗留一些痕迹和风险。比如GRUB配置如果被临时改动过虽然大部分场景是临时启动参数要检查是否有异常残留SELinux的relabel操作会触发重启后的自动标记过程这个过程在大型文件系统上可能耗时较长千万别以为机器卡死了。第三救援模式重置的是root密码但在现代云服务器环境中很多用户是用普通账号加sudo的方式来管理的。如果这次故障是由普通用户密码遗忘引起的恢复root密码后还需要把普通用户密码一并重置或者直接创建新的管理用户。我经常见到有人重置了root密码后就以为万事大吉结果应用服务还是起不来因为应用配置里用的是另一个服务账号密码同样到期了。5. 密码策略、权限陷阱与防坑指南5.1 密码强度与有效期配置密码修改本身不难难的是合理的密码策略。作为一个长期实践者我认为一个合格的服务器密码策略至少要覆盖四个维度长度、复杂度、有效期、历史次数。长度和复杂度在/etc/security/pwquality.conf中配置我已经在前面提到了minlen、dcredit等参数。实际操作中管理员在做完密码策略调整后需要立刻测试效果。测试方式就是尝试执行passwd设置一个不符合策略的密码观察是否会被拦截。有些管理员改完配置后不验证结果部署上线时才被反馈说“密码怎么都改不了”很被动。有效期配置通过chage命令完成。查看用户密码过期信息sudo chage -l zhangsan设置90天有效期、提前7天警告sudo chage -M 90 -W 7 zhangsan-M指定最大有效期天数-W指定过期前警告天数。还可以设置账号的失效日期-E这个参数在做临时账号时特别好用。比如给外包团队开一个从今天起存活30天的账号就可以chage -E 2026-06-30 zhangsan到期后账号自动失效无需手动删除。密码历史是另一个容易被忽略的环节。/etc/pam.d/system-authRHEL系或/etc/pam.d/common-passwordDebian系中可以配置rememberN参数让PAM记住最近N次使用的密码防止用户反复使用同一个密码。注意这个参数不是万能的它只在通过PAM的密码修改流程中生效直接改/etc/shadow绕过PAM的历史记录约束是可以的但这种操作本来就属于特殊管理场景。5.2 权限层级中最容易踩的三个坑第一个坑是sudo权限的配置不当。很多人在/etc/sudoers里给普通用户配置了类似zhangsan ALL(ALL) ALL的规则本意是让特定用户可以使用sudo执行管理命令。但这条规则同样允许该用户执行sudo passwd root相当于间接获得了root权限。我建议如果你只想让用户能管理某一个服务就把sudo规则细化到具体命令比如zhangsan ALL(root) /usr/bin/systemctl restart myapp这样该用户只能执行这一个命令权限收敛了很多。不要嫌配置麻烦权限整改的成本永远比安全事件后的复盘成本低得多。第二个坑是误用passwd命令导致锁死自己。典型场景是管理员在/etc/passwd或/etc/shadow中手工编辑文件时出现了语法错误比如字段数量不对、密码哈希里混入了非法字符会导致所有用户无法登录。处理这类问题时务必在改动前对/etc/shadow做备份并确认备份文件权限是600。还有一种是自己把root密码设置为空或错误地执行了passwd -l然后重启后发现再也无法登录。所以我养成了一个习惯在修改root密码后不立即重启服务器而是先开一个新的SSH会话验证新密码可以登录再继续后续操作。这条建议特别重要尤其是在远程维护服务器时一旦旧会话断掉而新密码又验证不过你就把自己锁在门外了。第三个坑是混淆了密码锁定和账户过期的区别。passwd -l锁定的账号其密码验证会失败但密钥登录、服务账号运行等通常不受影响usermod -L和passwd -l在历史语义上略有差异有些发行版简化了实现。而chage -E设置的账户失效日期作用是在指定日期之后该账号无法再登录系统。这两种机制的目的不同不要混用。比如你想临时停用一个员工账号正确做法是锁定密码并检查其进程而不是只设置很短的失效日期。6. 高频问题排查与实操经验6.1 典型报错与解决方案对照密码操作中遇到的报错大多数集中在以下几种我整理了一个速查对照表报错或现象根本原因解决方案passwd: Permission denied当前用户权限不足使用root或sudo执行passwd 用户名passwd: Authentication token manipulation error/etc/shadow权限异常或只读挂载检查shadow权限是否为-rw-------确认文件系统非只读BAD PASSWORD: it is too simplistic/systematic新密码不符合复杂度策略更换更复杂的密码或临时调整/etc/security/pwquality.confsu: Authentication failureroot密码与当前用户密码混淆确认使用的账号是否正确尝试sudo passwd root重新设置chage: user xxx does not exist用户名拼写错误或用户不存在先用id 用户名确认账号存在修改密码成功但SSH登录失败SSH配置禁用了密码认证或PAM配置异常检查/etc/ssh/sshd_config的PasswordAuthentication和 PAM配置其中Authentication token manipulation error是最让人头疼的一个。常见的原因是/etc/shadow文件被设置成了不可修改状态比如管理员执行过chattr i /etc/shadow。解决方法是先用lsattr /etc/shadow查看属性如果带i标志需要用chattr -i /etc/shadow解除锁定后再修改密码。这个陷阱往往不是配置错误而是防御性操作带来的副作用排查时要有这个意识。6.2 一些能让你少走弯路的经验最后分享几条我在实际运维中沉淀下来的经验不是文档里能查到的但对生产环境非常有价值。第一改密码前先检查当前会话的身份确认方式是否可靠。我见过不止一次管理员在终端里执行了sudo passwd root结果因为键盘布局不同新旧密码里的特殊字符输错了然后所有凭据全部失效。稳妥的做法是修改前先验证一次当前密码是否有效修改后再立刻用另一个终端验证新密码能正常登录全程不要断开旧会话。这条“先开逃生窗口”的规则比任何密码策略参数都更重要。第二自动化的密码轮换脚本里务必包含错误处理。用chpasswd批量改密码时如果某个用户名不存在整个脚本默认可能继续执行而不报错。我建议脚本中逐行读取用户列表每一行执行后解析返回值遇到非零退出码就记录下来最后统一汇总。不要依赖终端上飘过的警告信息生产环境里没人会实时盯着输出看。第三注意涉密场景的文件清理。passwd命令交互输入密码时不会留下历史记录但管道方式传入密码时bash的历史文件里可能记录下完整的命令内容。如果你使用了echo user:pass | chpasswd检查一下~/.bash_history如果记录了明文密码记得清理。更安全的替代方案是用read -s读取密码到变量再通过管道传给chpasswd或者干脆用密码文件加标准输入的方式但用后立刻删除文件并shred覆盖。第四在云服务器和虚拟化平台环境中密码修改完毕后建议做一次快照或镜像备份。原因很现实救援模式下的步骤如果出现意外——比如GRUB配置被误改、内核参数残留——恢复原始状态的成本远大于快照的成本。我通常在重置root密码或者大规模调整用户策略之前都会先拍一个快照这在操作失误时能直接回滚是非常高效的兜底手段。修改密码这件事看起来简单背后的机制、策略和风险其实不少。如果你正在维护一台Linux服务器我建议你从现在开始就建立一套完整的账号管理清单root密码多久轮换一次哪些普通用户拥有sudo权限密码策略参数是否已经成文规范/etc/shadow的备份无法恢复时的应急预案是否明确。把这些理清了密码修改就从“临时救火”变成了日常运维中一件闭环、顺手的小事。
阅读完成 · 觉得有帮助？
