上周同事跑来找我说他把root密码改了结果系统能登录了但数据库那边全线报错连接全断。我第一句话问他“你改的是操作系统的root还是MySQL的root”他愣了半天说是root啊不就一个root最后排查下来他改的是系统账号而应用连的一直是数据库自己的root账号。这个场景我见了太多次了。“root”这个名词在运维里就是个重灾区Linux系统有超级管理员rootMySQL/MariaDB里有同名账号sudo可以在不切换用户的情况下临时借用root权限某些环境检测工具还会把“是否有root权限”当成一项检查项。所以一搜“修改root密码”很多人上来就执行根本不问自己被卡在哪一层。这篇文章我想把“修改root密码”这件事按场景拆开写清楚Linux系统root密码怎么改、密码忘了怎么救回来、Ubuntu/CentOS/ESXi虚拟机各自的坑在哪、MySQL/MariaDB的root密码怎么改、1045和1396这两个让人头疼报错到底怎么回事以及改完密码后要联动检查哪些东西。内容偏实战适合刚碰Linux服务器的同学也适合被数据库连接问题折腾到半夜的老手对照查漏。1. 改root密码之前先把这几种“root”分清楚1.1 系统登录账号rootuid0的超级管理员Linux系统里root不是一个特殊符号而是一个真实存在的账户。这个账户在安装系统时创建uid固定为0拥有全系统最高权限可以读所有文件、改所有配置、杀任何进程、管理所有用户。修改这个账号的密码靠的是passwd root或者sudo passwd root密码最终被写入/etc/shadow文件。你输入的每一笔密码都会经过hash加密后存储正常情况下没有人能通过/etc/shadow反推原文所以运维这行一直强调root密码忘掉后没法找回只能重置。系统root密码的主要应用场景是本地登录控制台、SSH登录服务器、用su切换到root账户。如果你只是日常管理Linux服务器平时通过普通用户加sudo干活那root密码可能长期用不上但又不能没有一旦要用就是救命的。1.2 数据库里的root账号MySQL/MariaDB的管理员账号数据库的root账号和操作系统root账号完全是两套体系。MySQL/MariaDB安装完成后会在自己的用户表mysql.user里写入一行或多行root记录每行数据同时包含用户名和主机来源。这能解释很多诡异现象你执行mysql -uroot -p登录时客户端从localhost连接MySQL会匹配rootlocalhost这一行你从另一台机器连匹配的可能是root192.168.1.%或root%这些记录对应不同的host完全可以有不同的密码。所以修改数据库root密码必须清楚自己改的是哪个维度的root。经常有人只改了rootlocalhost结果应用服务器走远程连接仍然报错因为远程连的是另一个root。1.3 别把普通sudo权限误当成root账户sudo是另一个容易混淆的点。sudo passwd root执行时只是借用当前用户的sudo权限去修改root密码整个过程你不会变成root用户。很多新人执行sudo su成功后以为已经切到root了其实只是shell环境变了系统账户概念上还是那个普通用户只是权限提升而已。想做自检可以执行id root看uid是否为0或者看whoami的输出。下面这张表建议保存下来能省掉很多沟通成本场景账号类型修改命令验证方式Linux系统root操作系统账户passwd rootsu - root或ssh roothostMySQL/MariaDB root数据库账户ALTER USER/SET PASSWORDmysql -uroot -psudo授权权限机制不是账户passwd root可被授权sudo -l查看可用命令2. 系统root密码的常规修改passwd、sudo和锁定的关系2.1 最标准的修改姿势直接passwd能登录root账户的情况下修改root密码就是一条命令的事passwd输入当前密码之后连续输入两次新密码即可。如果当前是普通用户想改root密码则用sudosudo passwd root注意sudo版本和系统配置不同可能不会要求你输入当前root密码而是验证当前用户的sudo权限。这种情况下只要当前用户有sudo权限就能修改root密码。这也是为什么后台运维通常建议能用sudo的普通用户不要共享root密码。我个人习惯是在修改root密码之后马上执行一次su - root验证不要因为passwd提示“all authentication tokens updated successfully”就觉得万事大吉。密码策略、PAM配置异常时这条提示照样会出但新密码可能在实际登录时被PAM拒绝。2.2 su切换时提示“鉴定令牌操作错误”的常见原因网上热搜里有一条很典型“设置root密码时su: 鉴定令牌操作错误”。这个问题我踩过不只一次最常发生在你想从普通用户切换到root的时候。root对普通用户执行su - root时系统会拿用户输入的密码和/etc/shadow里root的hash做比对。如果比对失败就会提示鉴定令牌操作错误。常见原因有三个密码确实输入错了这是最简单的但往往最不容易承认root账号的密码字段被锁定比如shadow里root那行密码位是!或*PAM认证模块配置有问题比如/etc/pam.d/su里加了额外限制。排查时先用root权限看一下shadow文件sudo awk -F: /^root/{print $1, $2} /etc/shadow如果第二个字段以!开头说明root密码已被锁定。此时虽然可以继续以普通用户sudo但root密码本身是不可用的需要先解锁sudo passwd -u root然后再设置新密码sudo passwd root千万别在root锁定状态下反复“重设”密码你会发现无论设多少次su永远报同样的错因为锁定标志没有解除。2.3 用passwd -l锁定root账号和改密码是两码事很多人把passwd -l root理解成“改了root密码”。它做的事情是给shadow里的密码字段加一个锁定标记效果是root密码验证永远失败但密码内容其实没有被修改。这个操作在安全加固场景里很常见比如你希望禁止直接用root登录所有人都走普通用户加sudo。但后果也要清楚已经建立的root会话不会立刻断开SSH的root登录会被拒绝除非PermitRootLogin改为prohibit-password仍然允许密钥登录一旦sudo用户也没了就等于把自己锁门外了。所以我给团队定的规矩是可以禁用root密码登录但千万别在没有任何备用入口的机器上执行passwd -l root。至少确保有两个SSH会话开着或者保留物理控制台访问能力。3. 忘记root密码的抢救流程单用户模式与救援模式实操3.1 Ubuntu系列GRUB编辑参数进入单用户模式最常用、最通用的“救密码”办法是让系统不进正常登录流程而是启动到一个临时shell在这个shell里直接修改root密码。Ubuntu桌面版和服务器版操作略有不同但核心思路一致。以Ubuntu 20.04 / 22.04为例重启服务器在GRUB菜单出现时把光标停在第一行“Ubuntu”按e编辑启动项找到以linux开头的那一行通常是内核加载行在行尾删除可能的临街参数然后追加single或者init/bin/bash按F10或CtrlX引导启动。如果追加的是single系统会进入单用户模式出现一个root shell。此时直接执行passwd root如果追加的是init/bin/bash进入的是一个只有根文件系统的bash需要先重新挂载根目录为可写mount -o remount,rw / passwd root改完后用sync写盘然后执行exec /sbin/init或reboot -f重启。实测中reboot -f更保险因为此时init进程可能没有正常加载。3.2 CentOS 7 / RHEL 系列用rd.break打破启动流程CentOS 7用的是GRUB2步骤和Ubuntu类似但要小心SELinux和根目录挂载状态。重启后在GRUB界面按e找到linux16或linux开头那一行找到ro参数把ro修改为rw并在行尾追加rd.break按CtrlX启动。进入一个switch_root:/#提示符后根文件系统是只读的而且当前实际挂载的并不是完整根目录而是initramfs下的临时根。你需要先执行mount -o remount,rw /sysroot chroot /sysroot passwd root如果之前没有把ro改成rwchroot进入后/仍可能是只读执行passwd会失败。另外改完密码后建议执行touch /.autorelabel在CentOS 7里这个动作会触发下次启动时重新对SELinux安全上下文打标签。如果你跳过这步系统有可能因为/etc/shadow文件的上下文异常而启动失败或无法登录。这里多说一句手上的生产服务器如果开了SELinux重置密码后最好都执行一次这行命令。3.3 ESXi虚拟机里Ubuntu忘密码CtrlD卡住的解围思路很多人在ESXi的虚拟机控制台里重启Ubuntu进入恢复模式后想通过菜单里的“root Drop to root shell prompt”重置密码结果发现一直显示Give root password for maintenance或者Press Enter for maintenance按CtrlD也进不去。原因通常是系统启用了systemd的维护模式而这种模式要求先验证root密码陷入死循环你不知道root密码它又不让你跳过。处理思路不是硬等而是回到GRUB引导参数上。在ESXi虚拟机的控制台里重启客户机在GRUB界面按e直接编辑启动参数走单用户模式不要选择恢复模式菜单。具体方法和第3.1节一样追加init/bin/bash或single。这里是纯字符界面对于ESXi自带的web控制台也能正常操作不需要额外接键盘。如果你按了多次Shift或Esc都进不了GRUB菜单常见原因是GRUB配置里超时时间被改成0或者启动时web控制台没有及时捕获键盘输入。这种情况建议在虚拟机配置里挂载一个Ubuntu安装ISO从ISO启动选择“Try Ubuntu”进入Live环境然后挂载虚拟机的根分区直接编辑shadow文件或chroot重置密码。流程虽然比GRUB编辑长但在虚拟化环境里非常稳。4. MySQL/MariaDB的root密码改密、1045和1396的底层逻辑4.1 数据库root密码的正常修改姿势在能登录数据库的情况下修改root密码最推荐的方式是ALTER USER rootlocalhost IDENTIFIED BY 新密码; FLUSH PRIVILEGES;这个写法适用于MySQL 5.7和MariaDB 10.2。如果你处理的是老版本或者正在用MySQL的SET PASSWORD也可以这样写SET PASSWORD FOR rootlocalhost PASSWORD(新密码); FLUSH PRIVILEGES;强调一点MySQL的密码哈希算法、认证插件如caching_sha2_password、mysql_native_password会影响连接。新版本MySQL默认认证插件让很多老客户端报“Authentication plugin”错误所以如果你还要维持某些老程序连接改密码时可以考虑指定认证插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 新密码;生产环境执行前先用SELECT user, host, plugin FROM mysql.user WHERE userroot;看一下这个root一共有几行记录改的角色对应哪一行的host。只改rootlocalhost不等于远程root也被你改了这是新人最容易踩的坑。4.2 error 1045 Access denied不只因为密码错1045是所有MySQL用户最眼熟的报错。字面意思是“访问被拒绝”但底层原因可以有好几层第一层是密码错误。using password: YES表示客户端确实带了密码但服务端比对后不匹配。处理方式无需多言确认密码即可。第二层是认证插件不匹配。安装MySQL 8.0后root默认用caching_sha2_password如果你手动改密时用了旧的native_password语句或者某些老版本程序内置的认证协议压根不支持新插件也会表现为1045。这种情况下报错信息往往附带“Authentication plugin”字样解决方法是显式指定IDENTIFIED WITH mysql_native_password。第三层是host匹配问题。MySQL在验证用户时会根据客户端来源IP解析出来的主机名去匹配mysql.user表里的记录。比如报错里出现rootdesktop-1vncs7q说明客户端机器的主机名是desktop-1vncs7q而user表里没有对应的rootdesktop-1vncs7q。你可以把应用连接改成从localhost连也可以为这个host创建一个用户。如果实在登录不了数据库就要用skip-grant-tables进入维护模式systemctl stop mysql mysqld --skip-grant-tables --skip-networking mysql -uroot FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;注意--skip-networking一定不能省否则任何人在这段时间内都能免密连数据库生产环境这么干非常危险。改完密码立刻重启MySQL并确认skip-grant-tables参数没有被写进配置文件。4.3 error 1396 Operation ALTER USER failed命令和目标账号不匹配1396报错经常出现在执行这样一段命令时ALTER USER root% IDENTIFIED BY 新密码;结果告诉你说ERROR 1396 (HY000): Operation ALTER USER failed for root%。原因多数不是权限不够而是你要改的这个用户根本不存在。比如user表里只有rootlocalhost你却去改root%。遇到这种报错先查表SELECT user, host FROM mysql.user WHERE user root;如果确实没有你要匹配的host记录就不要强行ALTER而是把目标账号创建出来CREATE USER root% IDENTIFIED BY 新密码; GRANT ALL PRIVILEGES ON *.* TO root% WITH GRANT OPTION; FLUSH PRIVILEGES;少数情况下1396还和binlog回放、lower_case_table_names配置有关但绝大多数是host写错了。这里再感叹一句很多数据库问题不是配置有多难是账号的“全名”里那串host太容易被忽略。4.4 mysql允许root远程登录要改的几个地方远程登录是热搜词里的高频需求。做法分两步一是让MySQL服务监听外部地址二是允许特定host的root账号登录。查看监听配置bind-address 0.0.0.0 # 或注释掉 bind-addressMySQL 8.0里同样要注意如果你的机器有多块网卡bind-address默认值是127.0.0.1外部请求一律进不来。改完配置后重启服务用netstat -anpt | grep 3306或ss -lntp | grep 3306确认监听地址不再是127.0.0.1。然后授权远程rootCREATE USER root192.168.10.% IDENTIFIED BY 一个复杂密码; GRANT ALL PRIVILEGES ON *.* TO root192.168.10.% WITH GRANT OPTION; FLUSH PRIVILEGES;安全上是真心不建议开root%。至少把网段限制到内网网段再配合防火墙只允许某些应用服务器IP访问MySQL端口。否则你前脚开了远程root后脚就可能被扫库攻击盯上光靠设密码是挡不住暴力破解的。5. 改完root密码之后的联动检查与个人操作习惯5.1 系统侧受影响的服务、计划任务和已有会话改完系统root密码不是su能进去就结束了。你需要立刻检查这些东西当前所有已经建立的SSH会话还能继续用不会因为改密码就被踢掉。但如果你正在用ssh密码登录root一旦断开新连接的密码就是新密码写在脚本里的明文root密码全部失效检查crontab里有没有通过ssh root方式执行备份脚本的任务某些自动运维工具Ansible、SaltStack等如果通过root密码连接需要同步更新密码存储检查/etc/sudoers是否还正常。如果root被锁定、sudo规则又被改过就会发生“密码改好了但没有任何人能用”的连锁事故。我自己习惯在改密码前先开一个备用root会话然后在改密码后的第一分钟里专门验证新密码能登录、sudo命令能执行、至少一个运维平台能连上。三件事全部通过才算改密成功。5.2 数据库侧应用连接串和密码管理是最大的坑数据库root密码修改对在线业务的影响比系统root更大因为应用层往往存了旧密码。连接串里最常见的有jdbc:mysql://192.168.1.10:3306/appdb?userrootpasswordold_passdb pymysql.connect(host..., userroot, passwordold_pass)这类密码属于“长期隐藏在一堆代码里的定时炸弹”。建议团队统一用一个线上密码管理工具保存不要再把数据库密码直接写死在代码里。如果实在要用配置文件也建议对配置目录做权限收敛chmod 700 /etc/myapp/ chmod 600 /etc/myapp/db.conf改密上线时按顺序操作先改数据库密码再同步改所有应用连接最后重启应用验证。千万不要先重启应用、再改数据库那样会延长业务报错时间窗口。5.3 一个最小的验证清单比“环境检测工具”更可靠很多用户搜“环境检测工具大全root”期望有一个工具能一键检查root环境所有配置。但实际运维中真正需要看的就那么几个点检查项命令预期结果root密码是否可登录su - root切换到root提示符变成#root用户能否远程SSHssh rootlocalhost登录成功数据库root是否可连接mysql -uroot -p -h127.0.0.1进入mysql shell远程数据库连接是否正常用应用机器mysql -uroot -p -h服务器IP返回结果无1045关键服务是否恢复systemctl status mysql sshdactive (running)这套验证比任何花里胡哨的工具都直观能覆盖90%的“改完root密码后连不上”问题。踩过几次坑之后我现在对“修改root密码”这类活特别谨慎。最大的体会是分清root的类型比记命令更重要——系统root和数据库root是两套体系host字段决定了数据库root的真实身份改密码前一定要留一个备用通道改完密码后不要急着庆祝先跑一遍最小验证清单。尤其是数据库root改密前先SELECT user, host, plugin看一眼改完再用ALTER USER时心里就有底不会遇到1045和1396才手忙脚乱。最后提醒一句不管再怎么着急都别在没有任何回退方案的机器上执行passwd -l root这个坑我见得太多人掉进去了。