1. 修改密码的基础操作passwd命令的完整用法用Linux服务器这么多年修改密码应该是最常见不过的操作了。不管是刚拿到一台云服务器要做初始化还是运维过程中定期更换口令又或者是同事离职需要立即禁用账号都绕不开这个基础动作。可就是这么个基础操作在实际场景里坑也不少——有人改完密码登录不上有人忘了改的是哪个用户还有人在脚本里用passwd踩了交互式输入的坑。这篇就专门把Linux服务器改密码这件事从头到尾梳理一遍。1.1 登录状态下用passwd修改当前用户密码绝大多数人第一次在Linux上改密码用的都是这条命令passwd不带任何参数执行作用对象就是当前登录的用户。系统会先要求你输入当前的密码验证通过后再让你设置新密码而且输的时候不会回显屏幕上什么都不显示这是正常现象不是卡住了。新密码要连续输两次两次一致才会写入成功。这里有个很多人不知道的小细节当你是普通用户时passwd会强制要求新密码符合系统设定的复杂度策略——比如最短长度、必须包含不同类型字符等。但如果你用root执行passwd那么默认情况下即使新密码只有一位系统也会直接接受。这个差异在后面的安全加固部分很重要后面细说。如果是root想给别的用户改密码指定用户名就行passwd username这种情况下系统不会再问旧密码root有权限直接覆盖。我见过不少刚入行的运维在给同事重置密码时忘了这条命令会直接进入新密码设置流程结果把自己当前登录的账号密码给改了然后一脸懵。所以执行之前先确认一下当前用户身份养成好习惯。1.2 同时修改用户名与密码usermod和chpasswd的搭配用法如果你需要新建用户并设置初始密码通常会用到两条命令的组合useradd testuser passwd testuser但这样需要手动交互输密码在批量创建用户时不方便。用chpasswd就能一条命令搞定echo testuser:NewPass123 | chpasswd也可以批量处理多个用户格式就是每行一个用户名:密码echo -e user1:Pass123\nuser2:Pass456 | chpasswdchpasswd的优点是支持管道输入非常适合在脚本里用。Ubuntu和Debian系统还有个变体是chpasswd -e可以直接接收已经加密过的密码串这个在批量同步密码时很有用后面讲到多台服务器同步时会再次提到。1.3 修改密码后必须了解的登录验证技巧改完密码不代表事情就完了一定要验证能正常登录。常见做法是重新开一个SSH会话用新密码登录测试通过后再关掉旧会话。千万不要在唯一的管理会话里改密码还开着旧连接一旦新密码设置有误旧会话又断了你就被锁在服务器外面了。另外改密码不会影响当前已建立的SSH会话。只要会话还活着你仍然可以继续操作这是很多运维会忽略的点。合理利用这一点可以做到改完密码先验证新会话再清理旧会话把故障风险降到最低。2. 忘记密码的场景单用户模式与救援模式的完整操作如果说改密码是运维日常那忘了密码就是运维事故。处理这种问题的核心思路是在不需要原密码的情况下获得一个root权限的shell然后执行passwd修改密码。方法根据服务器的形态不同主要分两种物理机或虚拟机进单用户模式云服务器用控制台重置。2.1 CentOS 7进入单用户模式修改root密码CentOS 7在Linux服务器里占有率相当高所以单讲一下。遇到忘记root密码的情况操作思路是重启服务器在GRUB引导界面进行干预。具体步骤重启服务器出现GRUB菜单时在默认内核那一行按e键进入编辑模式。找到以linux16或linux开头的那一行通常是vmlinuz开头的在行尾追加一个单词rd.breakrd.break是systemd的一个内核参数它的作用是让系统在切换root文件系统之前停下来进入一个临时的initramfs环境这个环境里有最基础的工具集。按Ctrlx或者b键启动系统系统会进入一个switch_root环境的shell提示符。此时整个根文件系统是以只读方式挂载的需要重新以读写方式挂载mount -o remount,rw /sysroot使用chroot切换到真正的系统环境chroot /sysroot现在就可以执行密码修改了passwd root修改完成后需要处理SELinux的上下文问题。如果不处理可能导致重启后无法正常登录touch /.autorelabel这个文件的作用是告诉系统在下次启动时自动重新标记所有文件的安全上下文。连续输入两次exit第一次退出chroot环境第二次退出initramfs环境系统会继续启动。2.2 RHEL 8和CentOS 8系统的密码重置差异到了RHEL 8和CentOS 8时代重置密码的步骤略有变化。最显著的区别是在GRUB编辑时找到linux开头的行把rhgb quiet去掉然后在行尾追加rd.break后续的mount -o remount,rw /sysroot和chroot /sysroot操作与之前相同。关键差异是某些较新版本的系统光执行touch /.autorelabel可能耗时很长尤其是文件很多的时候系统会在启动阶段做全盘SELinux重标记可能需要几分钟到十几分钟。一个加速技巧是如果你的服务器没有开启SELinux或者不担心SELinux标签问题可以省去autorelabel。但这只适用于你知道自己在做什么的情况。如果服务器原本是开启SELinux的建议还是老老实实等autorelabel跑完否则重启后可能会遇到各种权限异常。2.3 Ubuntu和Debian系列的恢复模式操作Ubuntu和Debian也支持类似的单用户模式修改密码但入口不同。在GRUB界面按e编辑启动项找到linux开头的那行将ro quiet splash中的ro改成rw并在行尾追加init/bin/bash。追加这个参数后系统会直接启动到一个root shell而且根文件系统已经是可读写的。直接执行passwd root改完密码后执行exec /sbin/init或者直接reboot -f重启系统。不过Ubuntu默认根用户是被锁定的如果没有特别需要建议修改的是你常用的那个sudo用户而不是强行启用root。提示init/bin/bash这种方式在禁用GRUB编辑的加密环境或某些UEFI安全启动模式下可能无法生效这时候需要看具体系统环境做调整。2.4 云服务器的密码重置控制台与VNC的组合拳现在的服务器大多跑在云平台上遇到忘记密码的情况更好的路径不是去折腾GRUB而是直接使用云控制台的密码重置功能。不同的云厂商叫法不同有的叫重置密码有的叫重置实例密码操作大同小异在云控制台找到目标服务器实例选择重置密码或修改密码。按照提示设置新密码注意大小写、特殊字符的组合要求。重置后通常需要重启服务器才能生效。部分云厂商支持离线重置不需要关机这种方式更安全。这里有个细节需要特别留意云平台的密码重置功能在某些基于OpenStack等自建虚拟化平台或私有云环境中可能需要预先安装配置好cloud-init的密码注入服务。如果密码重置后无法生效优先级最高的排查方向就是先检查cloud-init是否运行正常其次检查网卡配置是否正确。如果这两块有问题重置功能大概率是废的得用VNC登进去手动处理。VNC访问路径一般也在云控制台里相当于直接接到了虚拟机的显示器上走的是虚拟键盘鼠标的通道和正常登录不一样。利用VNC可以进入GRUB界面执行上面说的单用户模式操作是云主机忘记密码的兜底方案。3. 批量场景下的密码管理多台服务器的同步与自动化单项操作掌握之后再来看规模化场景。手里有几十台服务器的时候一台一台手动执行passwd不现实。合理的思路是用脚本批量处理同时考虑密码的同步机制。3.1 用chpasswd和for循环批量重置密码假设需要把一批服务器上某个用户的密码统一改成新值可以用SSH配合chpasswd来实现。先准备一个服务器列表文件每行一个IP或主机名cat servers.txt 192.168.1.11 192.168.1.12 192.168.1.13再用一个for循环for host in $(cat servers.txt); do echo $host ssh root$host echo deployuser:NewPass2024 | chpasswd done如果服务器比较多建议用Ansible这类自动化工具写一个简单的playbook- hosts: all tasks: - name: Update password for deployuser user: name: deployuser password: {{ NewPass2024 | password_hash(sha512) }}使用Ansible的好处是自动处理了密码哈希不会以明文形式出现在历史记录或进程列表里而且自带错误处理和结果汇总。3.2 多台服务器密码同步的常见方案对比方案原理优点缺点手动逐台执行登录每台服务器执行passwd简单直接效率低易漏执行SSH批量脚本通过SSH远程执行命令灵活无需额外组件需要管理SSH密钥信任Ansible Playbook声明式配置管理可重复执行结果可追踪需要学习额外工具LDAP/SSSD集中认证认证统一走目录服务一次修改全局生效架构复杂依赖网络如果你的服务器数量超过三十台我的个人建议是趁早考虑集中认证方案比如FreeIPA或OpenLDAP。这样修改密码从登录服务器操作变成在管理端改一条记录本质上改变了问题模型运维工作量会少一个数量级。3.3 自动化修改密码脚本的注意事项编写批量修改密码的脚本时有几个地方容易被忽略密码不要出现在命令行参数或者脚本的进程参数里用history命令能看到。建议通过环境变量或交互式输入的方式传递或者用read -s来从标准输入读取。明文密码经过网络传输是巨大安全隐患。生产环境的加密通道是底线明文协议传密码这种事不要做。批量执行前先跑一台测试机验证目标服务器的网络连通性、SSH密钥信任和命令兼容性。等到全部执行完发现第一台就没成功再排查就晚了。执行完之后生成一份执行结果清单记录哪些服务器成功、哪些失败方便后续跟进。还有一个心得批量改完密码之后下一个动作一定是在一段时间内持续观察各服务器的登录日志和监控告警确认没有服务因为认证失败而中断。靠应用账号连数据库或第三方服务的场景改密码后要特别注意同步更新应用配置否则密码改了服务也挂了这个联动问题非常常见。4. 密码安全加固与策略配置从一次修改到长期治理修改密码这个动作本身很简单难的是怎么让服务器上的密码体系长期保持安全。这一节把密码策略、账号锁定、SSH认证配合这些相关点串起来讲。4.1 PAM密码复杂度策略配置实操Linux下密码复杂度是通过PAM模块控制的配置文件位置取决于系统版本和开启的功能模块。主要的文件是/etc/pam.d/system-authCentOS/RHEL或/etc/pam.d/common-passwordUbuntu/Debian。CentOS 7上启用密码复杂度校验需要确认pam_pwquality.so这一行没有被注释掉标准配置类似password required pam_pwquality.so retry3 minlen8 difok3各参数含义retry3允许用户输错3次。minlen8密码最短长度默认上限在模块编译时指定一般是8。difok3新密码与旧密码至少要有3个字符不同。ucredit-1、lcredit-1、dcredit-1、ocredit-1分别表示新密码最少需要包含大写字母、小写字母、数字和特殊字符各一个。参数比较多时一般把它们都写在同一行password required pam_pwquality.so retry3 minlen8 difok3 ucredit-1 lcredit-1 dcredit-1 ocredit-1改完之后可以用一个简单测试来验证echo testuser:weakpass | chpasswd如果策略生效这条命令会报错提示密码不符合要求。实际工作中我建议不要把规则设得过于苛刻比如同时要求大写、小写、数字、特殊字符、长度12位以上且每60天换一次这种策略会导致用户把密码写在便签纸上反而更不安全。合理和可用之间的平衡点需要自己把握。4.2 用户密码有效期与强制修改机制系统运维中另一个常见需求是新建用户时必须修改密码或者密码到期后强制更换。这涉及两个参数# 查看用户密码相关属性 chage -l usernamechage可以设置-M密码最长有效期天。-m密码最短使用期限天防止用户改完马上又改回去。-W到期前提醒天数。-d最后一次修改时间设为0表示强制该用户下次登录时必须修改密码。给新用户设置首次登录必须改密码的组合命令useradd -m -s /bin/bash newuser passwd newuser chage -d 0 newuser这样新用户拿到初始密码后第一次登录系统就会强制要求修改。这个操作配合前面介绍的批量脚本可以在大量创建临时账户时用安全又省事。4.3 用SSH密钥登录降低密码暴露风险密码再复杂也有被爆破的可能尤其当你的服务器SSH端口暴露在公网上时。更稳妥的做法是改用SSH密钥认证把密码登录彻底关掉。配置密钥认证的步骤比较简单在本地生成密钥对ssh-keygen -t ed25519 -C your_email_or_comment相比RSAed25519密钥更短、生成更快、安全性也足够是目前比较推荐的选择。将公钥安装到服务器上ssh-copy-id -i ~/.ssh/id_ed25519.pub userserver_ip测试密钥登录成功后修改服务器的/etc/ssh/sshd_configPasswordAuthentication no重启SSH服务systemctl restart sshd重启SSH之前必须确认你已经能用密钥登录否则重启完自己进不去。建议开两个SSH会话做保险一个会话改配置另一个会话保持不动。改完重启服务后先用新会话验证确认无误再关旧会话。4.4 密码文件的安全保护 shadow文件权限管理Linux系统把用户密码的哈希信息放在/etc/shadow文件中普通用户没有读取权限只有root和shadow组可以读。这是系统的一道重要防线。你可能会注意到passwd命令本身是个SetUID程序普通用户执行它时临时获得了root权限去写shadow文件但读取详细内容还是被禁止的。平时运维时不要随意去手动修改这个文件也不要轻易给普通用户添加shadow组的权限。每次执行完密码操作后可以检查一下权限有没有被意外改变ls -l /etc/shadow正常情况应该是-rw-r----- 1 root shadow 1234 Jan 1 00:00 /etc/shadow如果权限不是这个值需要立即修复。这是很多服务器安全加固检查项里的标准条目也是我日常巡检必看的内容之一。5. 常见问题排查与避坑记录这一部分整理的是实际运维中反复踩过的坑。每个问题都附上排查思路和解决方案当作速查表用。5.1 passwd修改成功却登录失败的排查方向现象执行passwd时显示passwd: all authentication tokens updated successfully但用新密码登录时总是提示认证失败。排查步骤确认你修改的是否是目标用户。比如用root执行passwd时不指定用户名默认改的是root自己不是当前登录的普通用户。这是最高频的低级错误。检查是否触发了密码错误次数锁定。多次输错密码后PAM的pam_faillock模块会把账号锁定一段时间。用faillock --user username --reset可以解开。看系统日志。CentOS/RHEL看/var/log/secureUbuntu/Debian看/var/log/auth.log。里面有具体的失败原因。检查是不是有PAM模块的额外限制。比如某些系统配置了密码不得与账号相同、不能与旧密码相似度过高等规则。确认键盘布局。如果是通过VNC或控制台登录某些虚拟键盘可能没有切到正确的布局导致输入的字符和预期不一致。5.2 键盘布局问题导致的密码错误一个容易忽略的坑这个问题据统计是改完密码登录不了的隐性原因前三名。云平台控制台的VNC通常是网页模拟键盘如果服务器原本配置的是非美式键盘布局或者你本机键盘是特殊布局在VNC里输入的符号可能和预期完全不同。例如你设置密码时包含了、#这类符号在键盘布局不一致的VNC窗口里输入可能实际发出的是、~之类的字符。此时密码设置已经成功但是密码内容跟你想的完全不一样。排查方法尝试在VNC的shell里手动输入密码串看屏幕上显示的键盘布局是否正常。如果发现字符不对可以先用localectl set-keymap us把键盘布局切到标准美式布局再执行passwd设置密码。5.3 SELinux上下文问题导致修改密码后无法登录在RHEL/CentOS系服务器上如果用chroot /sysroot方式修改密码容易遇到SELinux安全上下文不对的问题。直观表现是密码看起来修改成功了但重启后登录时还是失败或者SSH服务异常。这个问题需要有意识地预防按前面提到的生成/.autorelabel文件并重启让系统自动重置标签。因为你已经修改了shadow文件它的SELinux类型标签可能不再是shadow_t系统在登录验证用户时访问shadow文件就会受到限制。如果不想等自动重建也可以手动执行restorecon -v /etc/shadow来修复单个文件的标签。注意不要在开启SELinux的RHEL系服务器上禁用SELinux来绕过这个问题一旦关闭很多文件的上下文标签会在重启后混乱恢复起来更麻烦。5.4 使用chpasswd时特殊字符导致密码不生效chpasswd的输入格式是用户名:密码但如果密码里含有冒号:解析就会出现问题。比如你想设置的密码是Abc:123用echo user:Abc:123 | chpasswd执行后系统实际解析到的是密码Abc123则被当作额外内容忽略了。解决办法有两种密码中避免使用冒号这是在批量设置密码时需要提前考虑的规则。使用其他工具比如passwd交互式设置或者通过Python的crypt模块生成哈希后写入。另外某些特殊字符在Shell里需要转义这也容易引起误解。建议在脚本里统一用read -s交互输入密码配合变量引用从根本上避免转义问题。5.5 密码已修改但服务仍然使用旧密码的连锁问题很多服务数据库、应用账号、消息队列的连接信息是写死在配置文件里的。你修改了系统用户密码或者修改了MySQL、PostgreSQL等数据库账号的密码如果没有同步更新所有依赖该账号的应用配置就会引发大面积连接失败。特别是当我们修改MySQL的root密码时很多运维会手忙脚乱因为涉及的配置文件多关联的服务也多。有一个小技巧先一次性把所有配置文件里的旧密码查出来grep -r OldPass123 /etc /opt /usr/local 2/dev/null改完密码后用同样的方式检查还有没有残留的旧密码引用。这样可以防止因为漏改一处配置引发的故障。5.6 常见问题速查表问题现象常见原因解决思路修改成功但登录失败改错了用户明确指定用户名执行passwd并用whoami确认当前身份登录提示account locked输错次数过多被锁用faillock --user user --reset重置或等待锁定时间结束chpasswd批量设置后密码不能登录密码含冒号或特殊字符转义问题避免冒号用交互式输入或脚本变量处理特殊字符单用户模式改完重启无法登录SELinux上下文未更新执行touch /.autorelabel后再重启root密码改了所有普通用户也登不上也可能是PAM模块配置错误看/var/log/secure或auth.log排查PAM策略冲突密码改动导致依赖服务全部连接失败应用配置中的旧密码没有同步更新全局搜旧密码引用逐一替换并重启服务重置密码后未能生效云平台cloud-init异常或VNC通道故障优先排查cloud-init进程状态、网卡配置再考虑VNC手动操作6. 国产化服务器操作系统的密码修改差异随着信创和国产替代的推进我所在的运维团队也开始大量接触国产化系统其中使用频率最高的分别是统信UOS和麒麟系列。这些系统的底层基本都源自Linux内核很多命令和CentOS系、Debian系兼容但在细节上存在差异。修改密码这个基础操作在这些系统上也有需要注意的地方。6.1 统信UOS服务器版的密码管理指令统信UOS服务器版底层基于Debian体系所以passwd、chpasswd、chage这些命令的基本行为与Debian/Ubuntu保持一致。它的图形化管理工具如uos-account或控制中心相关组件也提供了用户密码管理入口在桌面环境下更直观。命令行层面需要注意两点UOS默认可能启用了更严格的口令策略通过/etc/security/pwquality.conf或相关的PAM文件进行配置。设置新密码时如果提示Bad password多半是复杂度要求没满足。UOS的安全中心组件可能会拦截或记录密码修改行为在某些等保合规场景下修改密码后需要同步检查安全审计日志确认记录完整。6.2 麒麟系统银河麒麟/中标麒麟修改密码注意事项银河麒麟服务器版分为基于CentOS 8和基于Debian的不同版本具体命令行为取决于底层架构先确认版本再操作。例如基于CentOS 8的版本单用户模式重置密码的方式与RHEL 8相同基于Debian的版本则更接近Ubuntu的方式。实际运维中国产化系统的密码策略默认值往往比纯社区版更强包含密码长度上限、历史密码不能被重复使用的次数、软/硬锁定策略等。如果你是想给某个应用账号设置一个简单密码用于测试很可能会被系统拒绝。这时候不要一上来就想着关闭PAM策略而是应该先确认应用是否必须用强密码如果是测试环境可以通过调整/etc/security/pwquality.conf来降低复杂度要求如果是生产环境最好保持默认策略。还有一个细节某些国产化系统的SSH默认配置里PasswordAuthentication可能已经是yes也可能被安全基线改了。改完密码后如果登录不了先检查sshd_config的配置和云平台/机房的安全组策略别一上来就怀疑密码设置的问题。7. 我的一点实践心得密码管理的运维习惯最后分享几个我这些年实际操作下来的习惯。这些不是教科书上写的但都是踩过坑之后总结的。第一每次修改密码后立即在一个本地加密的密码管理工具里更新记录。不要用明文Excel或者文本文件保存服务器密码哪怕只在你自己的办公电脑上也不行。我用的是支持加密和分类的管理工具同时配合团队共享的集中密码管理平台来流转权限。第二修改核心服务器密码之前先打开一个备用SSH会话保持连接。这个会话就是保险绳。如果改完密码后主会话断开了、新密码又怎么也登录不上你还有这个备用连接可以进去排查。等确认新密码完全可用后再关闭备用会话。第三所有需要设置密码的场景都优先考虑密钥认证而非纯密码认证。密码适合作为应急入口和日常审计凭证但真正日常操作的通道密钥认证更安全、更适合自动化。把密码登录关掉对公网服务器来说SSH爆破告警会瞬间少掉绝大部分。第四重要服务器数据库、网关、核心应用节点的密码修改尽量安排在变更窗口期执行并提前准备好回滚方案。不要心血来潮上午十点高峰期去改数据库密码。哪怕只是一个账号的密码都有可能导致连接池里的旧连接认证失败影响业务。第五密码策略不是越强越好。我记得有一次给一个老系统配置了超强密码策略结果业务方的脚本因为密码里不能包含某些特殊字符而无法改造整个上线计划被打乱。后来把策略调整成长度不低于12位 复杂度合理的组合两边都满意。密码安全的目标是平衡风险和可用性不是单纯追求看起来很难破。修改密码这个操作虽然基础但把它放在整个运维体系里看牵涉到的面其实很广身份认证、权限管理、自动化批量、安全基线、甚至是合规审计。把基础动作做扎实养成好的操作习惯才能在更大规模、更复杂的场景里不翻车。
