1. 为什么 Ubuntu 默认不给 root 密码先搞懂 su: 认证失败 背后的原因如果你刚从 CentOS 或者其他发行版转到 Ubuntu大概率会踩同一个坑打开终端输入su系统让你输密码你输完自己账户的密码结果啪一下弹出 su: 认证失败。然后你懵了觉得自己明明没输错密码为什么进不去 root这个报错我能理解因为我当初也在这个问题上卡过整整一个下午。关键问题在于Ubuntu 默认情况下根本没有给 root 账户设置密码它使用的是类似“锁定”的状态。所以无论你输什么密码哪怕是你自己账户的正确密码系统都会冷酷地告诉你认证失败。1.1 Ubuntu 的 sudo 设计哲学为什么默认锁定 rootUbuntu 从早期版本开始就默认禁用了 root 账户的密码登录转而推荐使用sudo。这个设计其实有很深的考量并不是单纯地“不让你用 root”而是为了安全性和可审计性。操作留痕使用 sudo 执行的每一条命令都会被记录到日志里通常通过/var/log/auth.log。一旦出了问题你可以明确查出来是哪条命令、哪个用户、什么时间执行的。而直接进入 root shell 之后所有操作都混在 root 身份下出了问题很难追溯具体是谁执行的。降低误操作风险使用 sudo 的时候每条特权命令前面都要加一个sudo这个“额外动作”其实是一道提醒让你停下来想想这条命令是不是真的要执行。这是非常经典的“防呆设计”。用户隔离root 是系统级账户一旦被攻破攻击者就拥有了整台机器的完全控制权。而普通账户即使被攻破权限也是有限的。1.2 “认证失败”的具体机制/etc/shadow 里的秘密要彻底理解为什么su会认证失败我们得看一眼 Linux 用户密码到底存在哪。密码并不是存在/etc/passwd文件里的而是在/etc/shadow文件里该文件只有 root 和有shadow组的成员才能读取。在终端执行sudo cat /etc/shadow | grep root正常情况下你看到的root行内容类似这样root:!:19199:0:99999:7:::看到第二段的!了吗这个感叹号就是问题所在。在 shadow 文件的密码字段中!表示“这个账户的密码已被锁定无法通过密码认证”。也就是说系统根本没有给 root 设置密码任何密码都无法认证成功于是你就收到了su: 认证失败。所以解决的思路就很清晰了给 root 账户设置一个密码把!替换成真正的密码哈希值。2. 从认证失败到成功切换3 步启用 root 账户如果你已经理解了上面的原理现在就可以动手了。过程很简单但我建议你按顺序执行尤其是第二步和第三步别看漏了。2.1 第一步使用 sudo 设置 root 密码首先确保当前登录的普通用户具备 sudo 权限。然后打开终端执行以下命令sudo passwd root系统会先提示输入你的普通用户密码这是 sudo 的认证之后会提示你输入新的 root 密码并且会让你再输一遍确认。注意输入密码时屏幕上不会有任何显示连星号都不会有这不是系统死机了只是终端默认不回显密码。成功执行后你会看到提示passwd: password updated successfully。这是最关键的一步它会把 /etc/shadow 里 root 行的!替换成一串加密后的密码哈希值root 账户从此有了“开门钥匙”。这里有一个顺带的细节此时如果再次执行sudo cat /etc/shadow | grep root你会发现!已经变成了一长串像$6$...的字符串这就说明密码已经设置好了。2.2 第二步用 su 切换 root 账户密码设置完成后执行切换su -注意这里我用的是su -中间有空格和短横线而不是单纯的su。这俩区别非常大su -登录式切换会重新初始化 root 用户的环境变量、当前目录切换到/root同时读取 root 的 shell 配置文件比如.bashrc、.profile。这是完整的“登录”动作。su不带横线非登录式切换仅仅把 UID 切换为 root但当前工作目录和大部分环境变量还是原来普通用户的。这在某些情况下会导致命令找不到、路径不对等怪异问题。所以我建议你养成习惯一律使用su -来切换到 root。执行su -后系统提示输入密码输入刚才设置的 root 密码回车。如果一切正常你的命令提示符会变成root主机名:~#注意最后的符号从$变成了#这是 shell 提示你当前拥有最高权限的标志。此时执行whoami返回root你就成功了。2.3 第三步确认并验证 root 状态成功切换之后建议顺手验证几个信息确认 root 账户确实处于正常启用状态id cat /etc/passwd | grep rootid命令会显示当前用户 UID 和 GIDroot 用户的 UID 是 0。这个我们之前讲过/etc/passwd里的 root 行存在说明账户没有被删除。如果id返回uid0(root)说明你已经完全切换到 root 权限了。注意UID0是 Linux 系统中“最高权限”的唯一标准。哪怕你把一个普通用户的 UID 改成 0它实际上就拥有了和 root 一样的权限所以千万不要随意修改 UID。3. 启用 root 后的日常管理常用命令与场景拆解root 账户启用后你有了两种最高权限操作路径一种是每次都sudo另一种是直接切换 root。但在实际使用中这两种方式的使用场景有明显区别我来说说我在工作中是怎么取舍的。3.1 sudo 和 su 在实战中的应用场景对比场景一日常单条管理命令比如你要重启 nginx 服务或者编辑/etc/hosts文件这种情况我更推荐用 sudo不需要切换到 rootsudo systemctl restart nginx sudo vim /etc/hosts好处是命令颗粒度小每一条都有日志记录不易误伤其他东西。场景二连续执行多条系统配置命令比如你在一台全新的服务器上初始化环境要创建目录、修改权限、写配置文件、装依赖包如果每条命令前面都敲sudo不仅费手指而且容易漏掉某一条导致权限错误。这种场景我建议直接切 root 干活su - mkdir -p /data/logs chown -R nobody:nogroup /data apt update apt install ...高效很多也方便整体控制。场景三写脚本批量授权或调整系统参数比如写脚本批量修改用户的 crontab或者调整内核参数写入 sysctl.conf我几乎都是在 root 状态下执行的。sudo 在脚本里面会出现奇怪的交互问题比如 sudo 缓存时间到期后必须重新输密码很容易中断自动化任务。3.2 如何恢复“禁用 root”状态有些人设置完 root 密码后用了一阵子觉得不需要直接登录 root 了想恢复原来的“禁用密码”状态让 root 重新“锁起来”。操作也很简单sudo passwd -l root这个-l是 lock 的意思作用就是把 /etc/shadow 里 root 的密码哈希前面加上!等于再次锁住密码认证。执行之后你再用su - root 密码就会再次“认证失败”。但这个操作和userdel不同它并没有删除 root 账户只是禁用了密码登录不影响系统底层的 root 权限。下面这个表可以很直观地对比一下“锁定”和“解锁”的状态状态shadow 中 root 行密码字段su 认证结果恢复方法初始默认!认证失败sudo passwd root启用状态$6$...哈希值输入密码后成功无需操作重新锁定!$6$...认证失败sudo passwd root重新设置我一直认为root 账户就像一把车的备用钥匙。平时你可能根本用不上但真到系统维修、救援、进单用户模式这些关键时刻你没有这把备用钥匙就只能干瞪眼。所以我的建议是密码可以设置好但日常尽量少用、甚至不用把它留作紧急救援通道。3.3 使用 root 账户时的环境变量疑问切到 root 之后有时执行python或者java提示命令找不到但明明是刚才装好的软件。通常问题和 root 的环境变量 PATH 有关系。普通用户常用的 PATH 路径里可能有/usr/local/bin、/home/用户名/.local/bin等而 root 用户的 PATH 可能并不包含这些东西尤其是一些用户级安装的软件。解决方式也很简单要么指定全路径执行/usr/local/bin/python3要么把相关路径追加到 root 用户的.bashrc中echo export PATH$PATH:/usr/local/bin /root/.bashrc source /root/.bashrc不过在修改 PATH 之前我强烈建议先看看原本的 PATH 是什么别直接覆盖。我见过有人把 root 的 PATH 改错导致ls、cat这些基础命令都找不到的惨剧。4. 图形界面和 SSH 登录 root 的扩展玩法除了终端suroot 账户启用后还会影响到另外两个入口图形化登录界面和 SSH 远程登录。这俩和终端切换是两码事需要单独配置我先说重点都有安全风险别为了省事放松警惕。4.1 图形登录界面默认情况下 root 不显示Ubuntu 桌面版的登录界面默认不显示 root 用户即使用户已启用密码。如果你确实需要用 root 直接登录图形桌面比如跑某些图形管理工具可以这样操作在 root 状态下编辑 GDM 的配置文件sudo vim /etc/gdm3/custom.conf在该配置文件中添加[daemon] Enabletrue但说实话平时我极其不建议这么做。图形界面登录 root 意味着你整个桌面环境都运行在最高权限下一旦浏览器、图片查看器这类应用出现漏洞被远程利用攻击者直接就拿到了最高权限。这个风险比 SSH 登录还难防因为图形界面应用数量大、攻击面广。4.2 SSH 远程 root 登录需要的配置和注意点SSH 默认配置是不允许 root 用密码直接远程登录的。即使你本地设置好了 root 密码远程用ssh rootip也会被拒绝。你需要在/etc/ssh/sshd_config中修改PermitRootLogin prohibit-password这个prohibit-password的意思是允许 root 通过 SSH 登录但只允许使用密钥认证禁止密码登录。把配置改成yes就是允许密码登录但代价是极容易受到暴力破解攻击。如果你非要远程 root 登录我的建议顺序是先把公钥认证配置好确认能用密钥登录再把PermitRootLogin改为prohibit-password最后重启 sshd 服务并保留一个普通用户登录窗口防止配置错误导致连不上机器。sudo systemctl restart sshd千万不要一上来就改成yes并加上密码登录特别是服务器暴露在公网的情况下扫描机器人能在几分钟内开始尝试暴力破解你 SSH 端口上的 root 密码。这不是吓唬你我自己就亲眼见过配置完密码登录后几小时内日志里刷出一大堆Failed password for root的记录。4.3 通过锁定密码回溯 root 是否“过期”的问题还有一个扩展技巧比较冷门适合有安全洁癖的朋友。如果某天你检查系统时发现 root 登录被拒绝但状态看起来不像被锁定那么可能是密码被设置了“过期时间”。sudo chage -l root这个命令会显示 root 密码的最后修改时间、过期时间、失效时间等信息。如果你看到Account expires是某个过去的日期说明 root 账户本身被设置了过期时间。这种情况下即使你密码正确系统也会拒绝登录。解决方法很简单sudo chage -E -1 root-E -1表示取消账户过期时间把它设置成“永不过期”。这个坑一般出现在某些系统初始化脚本或安全加固脚本中比较多见建议你排查 root 问题时也顺手看一下。5. 实际踩坑记录从“认证失败”到“成功切换”的完整过程这部分我在本地一台 Ubuntu 22.04 桌面版上完整走了一遍流程把每一步的输入、输出和关键截图感受都记录下来你可以对照着自己操作。5.1 现场记录按下 su 后的第一反应某个工作日的下午我在一台 Ubuntu 22.04 的机器上安装一个软件包需要 root 权限。当时的普通用户是demo。我打开终端准备直接切换到 root 执行安装命令。先用 CtrlAltT 打开终端输入su -终端提示密码我毫不犹豫地输入了demo这个用户的密码结果回车后立刻弹出一行红字su: 认证失败我当时的第一反应是“我是不是输错密码了”又试了一次还是认证失败。随后我怀疑键盘输入有问题用普通用户重新登录确认密码无误再试su结果依然一样。直到我想到查看/etc/shadow看到root:!才恍然大悟——Ubuntu 压根没给 root 设密码我却拿普通用户密码去试肯定是失败的。这个经历其实特别典型用 sudo 执行命令和用 su 切换 root两者要求的密码完全不同。sudo 要求你当前用户的密码而 su 要求目标用户root的密码。在 Ubuntu 默认状态下root 没有密码所以 su 永远无法认证成功。5.2 执行 sudo passwd root 时的输出细节在确认是密码未设置的问题后我执行了sudo passwd root输入 demo 的密码通过 sudo 认证后系统提示新的密码 重新输入新的密码这里值得强调一个细节我上面提过但值得再说一次这两次输入密码时终端上都不会显示任何字符包括星号也不会显示。这不是系统配置问题而是 Linux 终端的默认安全习惯。很多新手在这里会以为自己键盘坏了反复按几次键然后直接回车导致密码设置失败。正确做法是盲输密码输完直接回车然后再盲输一遍即可。设置成功后的输出是passwd已成功更新密码注意看英文系统里是passwd: password updated successfully。执行完成后我又检查了一次 shadow 文件sudo grep ^root: /etc/shadow输出变成了root:$6$Az5X6t0s...中间是一大串哈希值这次不再是!说明 root 已经被启用。5.3 切换成功后的环境验证清单密码设置完成后我重新执行su -这次输入新设置的 root 密码很快终端提示符变成了rootubuntu22:~#我看了一下pwd输出是/root说明环境变量确实被重置了对比非登录式su的pwd还是停留在原来的工作目录。我又跑了几条常用命令确认whoami cat /etc/os-release which apt输出分别是 root、Ubuntu 22.04.3 LTS、/usr/bin/apt一切正常说明 shell 环境完整可用。到这里从“认证失败”到成功切换 root 的完整链路就打通了。6. 日常使用中的其他疑问密码过期、usermod 锁定与安全建议最后这一部分我想把启用 root 后大家经常会问的几个问题集中整理一下顺便说说我在实际维护中总结的安全原则。6.1 如何彻底禁用 root 密码登录但不删除账户上面提到sudo passwd -l root是锁定密码。但还有另一种方式通过usermod把 root 账户直接设置为“过期”也能达到类似效果sudo usermod --expiredate 1 root这个命令的作用是把 root 账户的有效期设置成 1970 年 1 月 1 日账户直接就变“过期”了。此时即使密码正确也无法登录。如果以后想恢复用sudo usermod --expiredate -1 root就能重新激活。这两种方式对比一下锁定方式命令是否删除密码哈希恢复难度密码锁定passwd -l root密码前加!哈希保留低passwd -u root账户过期usermod --expiredate 1 root哈希本身不动标记过期中--expiredate -1我个人用的最多的是passwd -l因为恢复路径直观而且不会像“过期”那样让账户状态变得很难看不清楚。6.2 root 账户启用后是不是“必须”立即禁用很多安全文章看一眼标题就心惊认为只要启用 root 就是大逆不道。其实不必走极端。你要评估的是这台机器的使用场景个人的虚拟机或本地测试环境启用 root 密码无伤大雅反而方便。这种环境不接触外部网络风险基本可控。生产环境服务器建议保持 Ubuntu 默认的“禁用 root 密码 sudo”模型。日常操作都用 sudo特殊维护时临时设置 root 密码用完再快速锁定。有公网 IP 的云服务器一定不要开着 root 密码登录这是最容易被攻击的入口。要么公钥认证要么彻底禁 root SSH 登录。我在给出“启用 root”这类建议时一定会提醒使用者注意上面这层场景差异千万不要照搬一套配置到处乱用。6.3 我个人的操作心得与更安全的高权限方案在真实运维中我很少给 root 设置长期密码而是更倾向用“临时开启用完即锁”的方式。具体步骤是sudo passwd root # 执行需要 root 的维护操作 sudo passwd -l root这样做的好处是root 密码只在需要的时间窗口内存在其余时间都是锁定状态即使别人能看到 shadow 文件也只能看到!开头的锁定哈希。而且这个流程并不麻烦两次命令而已。另外如果你在团队协作环境中我更建议给个别成员配置sudo权限而不是共享 root 密码。在/etc/sudoers里给某个用户授权命令是这样sudo visudo然后添加user1 ALL(ALL:ALL) ALL这样既能完成管理工作又保留了审计日志出了问题可以定位到人比所有人共用一个 root 身份安全得多。这也是我踩过“多人共认 root 密码导致误操作无法定位”的坑之后最想强调的一点。启用 root 本身不是目的关键还是要建立一套合理、安全、可追溯的权限管理习惯不然密码设了也等于留下了安全隐患。希望这篇从“su: 认证失败”到成功切换 root 的完整经历能帮你少走我当初的弯路。
阅读完成 · 觉得有帮助?