企业官网建设流程全解析

1. 为什么 Ubuntu 默认不给 root 密码？先搞懂 "su: 认证失败" 背后的原因

如果你刚从 CentOS 或者其他发行版转到 Ubuntu，大概率会踩同一个坑：打开终端，输入su，系统让你输密码，你输完自己账户的密码，结果啪一下弹出 "su: 认证失败"。然后你懵了，觉得自己明明没输错密码，为什么进不去 root？

这个报错我能理解，因为我当初也在这个问题上卡过整整一个下午。关键问题在于，Ubuntu 默认情况下根本没有给 root 账户设置密码，它使用的是类似“锁定”的状态。所以无论你输什么密码，哪怕是你自己账户的正确密码，系统都会冷酷地告诉你认证失败。

1.1 Ubuntu 的 sudo 设计哲学：为什么默认锁定 root

Ubuntu 从早期版本开始就默认禁用了 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 root

id命令会显示当前用户 UID 和 GID，root 用户的 UID 是 0。这个我们之前讲过，/etc/passwd里的 root 行存在，说明账户没有被删除。如果id返回uid=0(root)，说明你已经完全切换到 root 权限了。

注意：UID=0是 Linux 系统中“最高权限”的唯一标准。哪怕你把一个普通用户的 UID 改成 0，它实际上就拥有了和 root 一样的权限，所以千万不要随意修改 UID。

3. 启用 root 后的日常管理：常用命令与场景拆解

root 账户启用后，你有了两种最高权限操作路径：一种是每次都sudo，另一种是直接切换 root。但在实际使用中，这两种方式的使用场景有明显区别，我来说说我在工作中是怎么取舍的。

3.1 sudo 和 su 在实战中的应用场景对比

场景一：日常单条管理命令

比如你要重启 nginx 服务，或者编辑/etc/hosts文件，这种情况我更推荐用 sudo，不需要切换到 root：

sudo 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 权限。

下面这个表可以很直观地对比一下“锁定”和“解锁”的状态：

我一直认为，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 的扩展玩法

除了终端su，root 账户启用后还会影响到另外两个入口：图形化登录界面和 SSH 远程登录。这俩和终端切换是两码事，需要单独配置，我先说重点：都有安全风险，别为了省事放松警惕。

4.1 图形登录界面：默认情况下 root 不显示

Ubuntu 桌面版的登录界面默认不显示 root 用户，即使用户已启用密码。如果你确实需要用 root 直接登录图形桌面（比如跑某些图形管理工具），可以这样操作：

在 root 状态下编辑 GDM 的配置文件：

sudo vim /etc/gdm3/custom.conf

在该配置文件中添加：

[daemon] Enable=true

但说实话，平时我极其不建议这么做。图形界面登录 root 意味着你整个桌面环境都运行在最高权限下，一旦浏览器、图片查看器这类应用出现漏洞被远程利用，攻击者直接就拿到了最高权限。这个风险比 SSH 登录还难防，因为图形界面应用数量大、攻击面广。

4.2 SSH 远程 root 登录：需要的配置和注意点

SSH 默认配置是不允许 root 用密码直接远程登录的。即使你本地设置好了 root 密码，远程用ssh root@ip也会被拒绝。你需要在/etc/ssh/sshd_config中修改：

PermitRootLogin prohibit-password

这个prohibit-password的意思是：允许 root 通过 SSH 登录，但只允许使用密钥认证，禁止密码登录。把配置改成yes就是允许密码登录，但代价是极容易受到暴力破解攻击。

如果你非要远程 root 登录，我的建议顺序是：

1. 先把公钥认证配置好，确认能用密钥登录；
2. 再把PermitRootLogin改为prohibit-password；
3. 最后重启 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 执行安装命令。

先用 Ctrl+Alt+T 打开终端，输入：

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 密码，很快终端提示符变成了：

root@ubuntu22:~#

我看了一下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，因为恢复路径直观，而且不会像“过期”那样让账户状态变得很难看不清楚。

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 的完整经历，能帮你少走我当初的弯路。