Ubuntu改密码这件事说起来特别基础但我在帮团队处理服务器问题的时候见过太多人栽在“改个密码”上。有的是忘了当前密码只能进救援模式有的是执行了sudo passwd之后自己都分不清改的是谁还有的配置了密码复杂度策略结果用“123456”一试竟然还是能通过。这篇文章就把Ubuntu修改密码和密码复杂度策略设置一次性讲透不同场景该用哪条命令、底层走的是什么认证机制、策略配置文件里的每个参数到底什么意思以及我实际踩过的一些坑。不管你是在虚拟机上刚装好Ubuntu还是在生产服务器上做安全加固这篇都能直接照着用。1. Ubuntu修改密码的几种场景与原理很多人觉得改密码就是一条passwd命令的事但Ubuntu下面至少能拆出三种完全不同的场景改自己的密码、管理员改别人的密码、忘光了进救援模式重置。每种的操作边界和底层逻辑都不一样我先把这个底层的认证关系理清楚后面配策略才不会懵。1.1 修改当前用户自己的密码普通用户改自己的密码终端里直接输入passwd系统会依次提示Current password: New password: Retype new password:这里有个容易翻车的细节输入当前密码时不会显示任何字符终端里看起来像没反应这是正常的。新密码输入时同样不回显而且要求输两遍确认两次不一致会报“Passwords do not match”。我见过不少新手在这里反复输错最后被PAM拒绝。Ubuntu默认的密码策略虽然宽松但新密码和旧密码过于相似、或者新密码就是账户名本身的时候也会被拒绝。比如用户名叫zhangsan新密码设置成zhangsan123系统会提示“contains the user name”然后拒绝。这个不是我瞎说是PAM底层的pwquality模块在起作用只是默认规则比较弱。还有一个关键点普通用户如果不知道当前密码是没有办法直接改自己密码的。这不是bug是安全设计。你不知道密码就说明你可能是拿到了一个已登录会话的陌生人系统不能让你随意替换主人的密码。这种情况下必须找管理员用下面的方法重置。1.2 管理员修改其他用户的密码管理员root或者有sudo权限的用户重置别人的密码用这条sudo passwd 用户名比如把zhangsan的密码重置为临时口令sudo passwd zhangsan执行后系统会直接提示输入新密码不需要输入该用户当前的旧密码。这一点在实际运维中特别有用用户离职、密码遗失、或者怀疑账户被入侵都可以直接在后台重置。管理员还可以用chpasswd做批量修改适合一次处理多个账号echo zhangsan:NewPasswd2025! | sudo chpasswd但这里有坑。echo这条命令会留在shell的历史记录里凡是登录这台机器的人用history命令就能看到明文密码。实际生产环境里我建议要么用带交互的passwd命令要么用管道从受控文件读取密码。如果一定要用echo记得用完清理当前会话历史或者临时关闭历史记录再执行。另一个高频误区是sudo passwd和sudo passwd root的区别。直接执行sudo passwd修改的是root用户的密码sudo passwd zhangsan修改的是指定用户的密码。看起来就差一个参数但后果完全不同。1.3 忘记密码时的救援模式重置真到了所有密码都忘光的那一步办法还是有的不需要重装系统。Ubuntu的救援模式就是为了这种场景准备的。第一种方式开机进GRUB菜单选择“Advanced options for Ubuntu”再选对应的内核的recovery mode进入后选择“root - Drop to root shell prompt”。这里需要注意进入root shell后文件系统通常是只读挂载的必须先执行mount -o remount,rw /然后再修改密码passwd zhangsan不执行remount直接passwd会报错说文件系统只读很多人卡在这一步。第二种方式更直接在GRUB菜单界面按e编辑启动参数找到以linux开头的那一行在末尾加上init/bin/bash然后按Ctrl-X启动。系统会直接进入bash再挂载根文件系统为可读写后重置密码。这种方式在VMware、VirtualBox这些虚拟机环境里非常稳定也是热词里面很多人问“虚拟机安装ubuntu系统之后忘记密码”时最常用的解法。这里有个补充如果系统盘做了LUKS全盘加密救援模式会先要求输入磁盘加密密码。磁盘加密密码和管理员密码是两套东西别混了。如果连磁盘加密密码也忘了那数据恢复的复杂度就完全不是本文能覆盖的了做好物理备份永远比事后补救重要。1.4 root、sudo与密码的底层关系很多初学者会被Ubuntu的root机制绕晕。Ubuntu默认安装时是不设置root密码的安装过程中创建的第一个用户拥有sudo权限日常管理走sudo提权。关键来了sudo在要求你输密码时要的是当前用户的密码不是root的密码。很多人所谓的“root密码不对”其实是因为根本没有给root设置过密码。如果哪天你确实需要root密码可以主动设置sudo passwd root设置完之后root账户就可以直接登录系统或者通过su切换到root。但这个操作同时会带来一个暴露面root是系统里唯一一个UID为0的账户一旦被爆破成功攻击者直接拿到全部权限。所以我个人在服务器上默认不启用root密码登录日常全部用sudo处理管理任务这样日志审计时能准确看到是哪个用户执行了哪条命令。理解了这个机制再回头看修改密码这件事改自己用passwd改别人用sudo passwd用户名改root用sudo passwd root三者指向完全不同的账户。后面配置密码策略时也分普通用户和root两种情况有些参数默认是不对root生效的这个我们下面细说。2. 密码复杂度策略PAM与pwquality配置修改密码只是起点真正保证系统安全的是密码复杂度策略。Ubuntu默认的密码策略非常宽松这是出于桌面用户体验考虑的但当这台机器是服务器时弱口令就是最大的漏洞。这一节讲清楚Ubuntu到底是怎么做复杂度校验的以及每个参数怎么调。2.1 为什么Ubuntu默认不强制复杂密码Ubuntu默认策略允许你设置一个很短的密码比如六位纯数字只要不是太离谱都能通过。原因是桌面发行版面向的是普通用户太多限制只会劝退人。但当机器上跑了业务、开了SSH这种情况就必须做加固。密码复杂度的底层实现是PAM。PAM是Linux认证体系里的插件化框架你可以把它理解成安检口的多个环节密码是身份证PAM模块是安检机器机器上装了什么模块、开了什么规则决定你能不能通过。Ubuntu负责密码质量检查的模块在20.04之后主要是libpam-pwquality更早的版本用pam_cracklib。两者理念类似但配置项和文件名有差异。先确认系统里装了没有dpkg -l | grep libpam-pwquality如果没输出手动安装sudo apt update sudo apt install libpam-pwquality -y装完模块后PAM的调用位置在/etc/pam.d/common-password文件里正常情况下会有一行类似password requisite pam_pwquality.so retry3这一行的含义是在修改密码流程中必须经过pam_pwquality.so模块的检查retry3表示用户最多输错3次新密码。如果这一行不存在后面配置文件写再多也不会生效。很多人策略不生效的第一个原因就是模块没装或没被PAM调用。2.2 pwquality.conf核心参数详解模块的具体规则写在两个地方老版本用/etc/security/pwquality.conf新版本还支持/etc/security/pwquality.conf.d/目录下的独立文件。Ubuntu 22.04两个位置都能识别但我建议在pwquality.conf.d目录下单独建一个数字前缀命名的文件比如01-secure.conf这样升级系统时主配置文件不容易被覆盖。先看一组最常用的生产环境参数minlen 14 dcredit -1 ucredit -1 lcredit -1 ocredit -1 retry 3 enforce_for_root 1每个参数的含义我整理成了表格参数含义配置示例minlen新密码最小长度但包含计分奖励机制minlen14dcredit包含数字的得分控制-1表示至少包含1个数字dcredit-1ucredit包含大写字母的控制-1表示至少包含1个大写字母ucredit-1lcredit包含小写字母的控制-1表示至少包含1个小写字母lcredit-1ocredit包含特殊字符的控制-1表示至少包含1个特殊字符ocredit-1retry用户输入新密码时允许重试的次数retry3difok新密码中必须有多少个字符与旧密码不同difok5maxrepeat同一个字符最多连续出现的次数maxrepeat3enforce_for_root对root用户也强制执行默认root不受限enforce_for_root1这里有个很容易误解的地方就是minlen的计分机制。按字面意思minlen14应该是至少14位但pwquality的实际算法是密码基础长度加上字符种类带来的奖励分数最终得分不低于minlen就算通过。也就是说如果设置dcredit-1、ucredit-1、lcredit-1、ocredit-1密码里同时包含数字、大小写、特殊字符时实际最短长度可能只需要8到10位就满足了。很多人配了minlen14用“Abcd1234!”这种十位不到的密码一试竟然通过了原因就在这里。如果你想要绝对的最小长度而不是计分后的等效长度可以把minlen提到16甚至更高并配合各种credit-1让长度和字符种类双重要求都拉满。但也不建议设太夸张密码策略的目的是挡掉弱口令不是让用户天天改密码改到崩溃。配置完可以用pwscore命令直接给密码打分验证规则是否生效echo StrongPassw0rd!2025 | pwscore分数越高越强如果密码不合格会输出BAD PASSWORD和具体原因。这个命令在调优策略时非常好用不用反复用passwd去试。2.3 密码老化与强制过期复杂度解决了密码本身弱不弱的问题但一个再强的密码用上三年也可能泄露。密码老化策略就是给密码设定生命周期到期必须更换。Ubuntu的密码老化信息通过chage命令管理。先看某个用户的当前设置sudo chage -l zhangsan输出会显示最近一次修改密码时间、密码过期时间、两次修改最小间隔、警告天数等。给用户设置90天过期、提前7天提醒、且修改最小间隔为0天sudo chage -m 0 -M 90 -W 7 zhangsan参数说明-m两次修改密码之间的最小天数0表示随时可以改-M密码有效的最长天数90表示90天后必须更换-W过期前多少天开始警告如果想让某个账号的密码立刻过期强制用户下次登录时先改密码sudo passwd -e zhangsan这个命令在给新员工发临时账号时特别常见管理员设置一个一次性临时密码用户第一次登录必须改成自己的密码管理员并不知道最终密码安全又干净。全局默认值可以写在/etc/login.defs文件里PASS_MAX_DAYS 90 PASS_MIN_DAYS 0 PASS_WARN_AGE 7注意这组配置只影响之后新建的用户对已有用户不生效。已有用户还是要用chage单独调整。生产环境里我建议配合批量脚本一次性处理所有存量账号别只改配置不落库。2.4 登录失败锁定策略密码复杂度挡得住弱口令挡不住暴力破解。服务器开了SSH公网上扫端口和试密码的脚本从来不消停。这时候需要登录失败锁定策略连续输错N次就锁住这个账号一段时间逼退爆破脚本。Ubuntu 22.04推荐用pam_faillock模块。配置位置在/etc/pam.d/common-auth需要按顺序加入以下几行auth required pam_faillock.so preauth audit silent deny5 unlock_time900 auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time900 auth sufficient pam_faillock.so authsucc audit deny5 unlock_time900同时在/etc/pam.d/common-account里加一行account required pam_faillock.so参数含义deny5表示连续失败5次锁定unlock_time900表示900秒后自动解锁也就是15分钟。管理命令faillock --user zhangsan # 查看失败记录 faillock --user zhangsan --reset # 手动解锁这里要特别提醒一个风险如果你在远程服务器上配错了faillock又用密码登录测试连续输错几次锁定的是你自己。等所有会话都断了又没有其他后路只能去机房或者控制台处理。配置这类锁定策略前务必先开一个已登录的root会话留着或者确保云控制台VNC能用。旧版本Ubuntu系统常用pam_tally2模块如果机器上两个模块同时启用可能会互相干扰造成重复锁定。迁移到新策略时先检查grep -r pam_tally2 /etc/pam.d/有输出就先清理掉相关行再启用faillock避免冲突。3. 实操记录给一台Ubuntu 22.04服务器配置完整密码策略理论讲完直接上一份真实操作记录。前阵子我接手一台Ubuntu 22.04的Web服务器上面有3个开发账号密码策略基本为零有人在密码里用了“123456”。安全审计提了一串要求我按步骤落实完后把这套流程整理在这里拿走就能用。3.1 背景与需求服务器情况Ubuntu 22.04 LTS开启SSH远程登录3个开发账号分别为zhangsan、lisi、wangwu均为sudo用户。审计要求四条密码最少14位必须包含数字、大小写字母、特殊字符密码90天强制更换连续5次登录失败锁定15分钟root用户也必须遵守同样的复杂度这个需求其实挺常见的对应等保测评里口令安全那几条。整个配置分两轮走先做复杂度再做老化和锁定。全部操作都建议用普通sudo用户执行不要直接开root。3.2 第一轮最小复杂度配置及验证先安装pwquality模块sudo apt update sudo apt install libpam-pwquality -y然后确认PAM调用行存在grep pam_pwquality /etc/pam.d/common-password输出里面有requisite那一行就没问题。接着在pwquality.conf.d目录下建策略文件sudo vim /etc/security/pwquality.conf.d/01-secure.conf内容minlen 14 dcredit -1 ucredit -1 lcredit -1 ocredit -1 retry 3 enforce_for_root 1保存后先不急着通知开发人员改密码自己本地验证一遍。用pwscore测试不同密码echo 123456 | pwscore会直接报BAD PASSWORD。再测一个符合规则的echo Abcd1234!efgh | pwscore能正常输出分数就说明策略生效了。我用实际操作的经验再说一句策略文件改完后对已经登录的用户、已经建立的SSH会话不会立刻踢下线但下一次任何方式修改密码时就会按新规则校验。所以这个策略是平滑生效的不用担心配置瞬间把所有人锁在门外。3.3 第二轮过期时间与失败锁定配置复杂度配置完先看当前账号状态sudo chage -l zhangsan输出大概率是“密码永不过期”也就是默认状态。批量设置三个账号90天过期、提前7天提醒for user in zhangsan lisi wangwu; do sudo chage -m 0 -M 90 -W 7 $user done同时强制所有人下次登录改密码sudo passwd -e zhangsan sudo passwd -e lisi sudo passwd -e wangwu如果你是运维负责人做这一步前一定先在工作群通知到位。不然开发人员早上登录突然被要求改一个14位带大小写特殊字符的密码很容易以为是系统出问题然后狂给你发消息。接着配faillock。编辑/etc/pam.d/common-auth在文件顶部按照PAM顺序加入前面说的那三行auth配置再在/etc/pam.d/common-account里加account行。保存后查看锁定功能faillock --user zhangsan没有失败的记录就正常。为了验证可以故意输错几次密码再查faillock就会看到deny计数。测试完别忘了解锁faillock --user zhangsan --reset经验是测试锁定功能时一定别在唯一的管理会话里做。我一般是新开一个SSH窗口故意输错原窗口保持不动这样即使新窗口被弹掉也没关系原窗口还能继续操作。3.4 策略生效后的日常维护提醒这套策略落地之后日常维护有几件事要定期做。一是看失败记录。被爆破的迹象在auth日志里非常明显通常是一堆IP反复尝试不同用户名sudo tail -f /var/log/auth.log | grep Failed password二是看账户状态。如果有人反馈登录不上先判断是密码错了、过期了还是被锁了sudo passwd -S 用户名看到L开头就是被锁了。再用faillock看失败次数确认不是误锁的话再决定是否解锁。三是配合SSH密钥。真正生产环境里不应该只靠密码登录SSH。密码策略防的是交互式弱口令而SSH密钥是一种更长、更随机、不需要人工记忆的认证方式。把SSH密钥登录打开关闭或限制密码登录密码策略主要用于控制台和sudo提权场景。这两者配合起来安全性才有质的提升。4. 常见问题与排查技巧实录配置过程中最容易出问题的地方集中在策略不生效、账户被锁定、sudo认证失败这几类。我把实际遇到过的情况整理成一份速查按现象、原因、解法挨个排好。4.1 修改密码后sudo突然用不了现象普通用户密码改完后执行sudo提示认证失败或者直接报错。排查看三个地方。第一确认密码改的是谁。如果执行了sudo passwd而不是sudo passwd 用户名实际修改的是root密码sudo认证时还是要输当前用户密码两者不是一回事。第二看账户是不是被锁定了。等保加固、或者之前配了faillock后密码改完账户可能还处于锁定状态用passwd -S查看如果是L开头就需要解锁。第三确认/etc/sudoers文件没有被误改。我见过有人chmod 000 /etc/sudoers结果sudo直接提示权限错误这种只能进救援模式修复。经验sudo权限恢复不了的时候不要慌着重装系统。Ubuntu可以启动到recovery mode把挂载改成rw然后用pkexec或直接修改配置文件来修复sudoers权限。快照备份在这种情况下是救命稻草。4.2 配置文件改了但策略不生效这是被问得最多的一个问题明明在pwquality.conf里写了minlen14实际设置“abc123”照样成功。按顺序排查libpam-pwquality模块是否安装。没装模块的话配置写哪里都是空谈。/etc/pam.d/common-password里是否有pam_pwquality.so这一行。被注释或行不在密码段就检查不到。配置文件位置是否正确。Ubuntu 22.04虽然支持pwquality.conf.d目录但文件名要有数字前缀比如01-secure.conf否则不读。老系统只认主配置文件pwquality.conf直接写主文件最稳。是否还存在pam_cracklib的调用。如果两个模块同时存在旧模块先执行可能直接放行了。系统版本差异。Ubuntu 20.04和22.04的PAM调用写法略有不同跨版本找答案时要留意。另外一个隐蔽问题有些桌面环境的图形化改密界面会走不同的认证通道配置终端passwd的规则不一定会完全反映在图形界面上。所以验证策略时务必在终端里用passwd实测而不是光看图形界面的提示。4.3 密码状态与账户锁定状态怎么看运维里最常用的三件套sudo passwd -S 用户名 sudo chage -l 用户名 faillock --user 用户名passwd -S的输出里有个状态字段P表示密码正常L表示锁定N表示无密码。chage -l输出密码过期时间、警告天数。faillock输出最近失败次数和锁定时间。再补一个看/etc/shadow的细节sudo grep 用户名 /etc/shadow密码字段以$6$开头是正常的SHA-512加密密码如果字段是!或*分别代表密码锁定和不能登录两个字符都有时说明密码为空且账户锁定。判断账户状态时这个文件比passwd -S更直接但也正因为敏感平时别乱读。4.4 自动化脚本与远程SSH会踩的坑服务器如果被监控脚本、CI/CD工具频繁用密码登录配置了失败锁定之后要格外小心。自动化工具如果还拿着旧密码或者配置文件的密码过期了它就会反复尝试结果就是把账号锁了顺带把整个发布流程卡住。我的处理习惯是自动化场景优先使用专用部署账号配SSH密钥不走密码认证。这样密码策略和锁定策略只管人肉登录机器认证走密钥通道两边互不干扰。如果确实有工具必须用密码记得定期同步密码别让密码过期时间卡在自动化流程里。另外批量改密脚本很容易留下历史记录。bash的history默认记录所有命令如果脚本里明文写密码换人登录这台机器时全部暴露。实际生产里我建议用环境变量或密码文件方式读取并设置文件权限600用完即删。远程SSH操作还有个黄金守则改动认证相关配置之前先开一个备用会话或者确认云控制台VNC可用。密码策略、faillock、sudoers、SSH配置这四个里面任何一个改错都有可能让你彻底失去远程入口。我个人的习惯是服务器上永远留一个已登录的root或sudo会话窗口等所有验证通过之后再关掉这个习惯帮我避免过好几次把自己锁在门外的尴尬。配好密码复杂度之后还可以继续往Fail2ban、双因子认证的方向扩展但那些是另一个话题了。先把基础的口令安全做扎实公网上那些脚本扫描和弱口令爆破大概率已经拿你没什么办法。