lloydsheng如果你是从 Ubuntu 18.04/20.04 一路升上来的老用户，或者刚从 CentOS 切换过来，第一反应大概率是：装完 Ubuntu 24.04 打开终端敲 su，然后发现 root 密码根本没设置过，系统直接告诉你“认证失败”。这不是你操作有误，而是 Ubuntu 默认就把 root 用户锁在门外了。我当年第一次用 Ubuntu 时也在这儿卡了半天，后来才明白这是 Debian/Ubuntu 系跟 RHEL/CentOS 系在设计哲学上的一个重大分歧。
这篇文章不是要把 root 密码交给你就完事，我会讲清楚“为什么 Ubuntu 要这么干”“哪些场景值得你打破这个默认设置”“怎么操作最不容易翻车”，以及“启用 root 之后会遇到哪些真实环境的坑”。基于 Ubuntu 24.04 的实测，覆盖实体机、VMware 虚拟机、云服务器三种环境，尽量让看完的人能一次搞定，不用再到处查。
1. 为什么 Ubuntu 默认不让你直接用 root，以及这样做到底图什么
1.1 Ubuntu 的 sudo 机制和它的历史根源
Ubuntu 从诞生那天起就默认禁用 root 超级用户，安装系统时让你建的那个账号，会被自动加入 sudo 组。这个设计不是 Ubuntu 拍脑袋想出来的，而是继承了 Debian 的传统，而 Debian 是江湖上出了名保守的发行版。
sudo 与直接使用 root 的核心区别，不在于“能不能拿到最高权限”，而在于“拿到权限之后要不要留痕、要不要输入密码”。普通用户执行 sudo command 时，系统会要求你输入当前用户的密码，然后在 /var/log/auth.log 里记录一条日志，内容包括谁在什么时候执行了什么命令。而直接以 root 身份登录系统后，终端上敲的每一条命令默认都不需要二次认证，日志里也不会自动关联到具体是哪个物理用户干的。
这套机制在单机开发环境里看起来有点多此一举，但在服务器环境非常关键。想象一个场景：三个人共管一台服务器，如果大家都用 root 登录，哪天有人执行了 rm -rf，出事了根本不知道是谁干的。如果大家都用 sudo 切换，日志会清楚地写着 user1 执行了删除命令，追责和复盘都很方便。
另外，从安全攻击面的角度讲，root 用户一旦存在且密码泄露，攻击者得到的就是一台完全沦陷的机器。Ubuntu 默认不设 root 密码，等于直接把这条攻击路径从原理上切断了。攻击者即便拿到了普通用户，也必须先破解 sudo 密码，而 sudo 密码就是普通用户自己的密码，这层认证粒度比直接搞 root 更细。
1.2 什么场景下你真的需要启用 root，什么时候其实不需要
我在实际使用中总结下来，值得启用 root 的场景无非这几类：
- 你有一台纯个人开发用的 Ubuntu，日常操作全是改系统配置、装软件、折腾环境变量，sudo 每次输密码确实烦，直接切 root 省事。
- 你要在 VMware / VirtualBox 虚拟机里做系统实验，比如编译内核、修改系统级服务、模拟生产环境故障，这些操作往往需要持续一段时间的 root 权限，每次 sudo 会影响实验节奏。
- 你在写运维脚本或自动化任务（比如 cron 里的备份、清理日志），脚本内部需要大量系统级权限，用普通用户 + sudo 配 NOPASSWD 也行，但直接 root 更省心。
- 你要调试某些需要特权才能响应的事件，比如抓网络包、挂载文件系统、修改硬件参数，这些命令在普通用户下要么需要 sudo，要么直接报错。
反过来，这些情况下我强烈建议你不要启用 root：
- 服务器上有多个使用者，哪怕都是可信任的人，也尽量别开放 root 直登。用 sudo + 日志是性价比最高的方案。
- 你的 Ubuntu 是给家里人或者同事当日常桌面用的，系统里跑着浏览器、办公软件、输入法。这类场景一旦默认登录 root，哪怕一次误操作点击了某个需要 root 权限的清理脚本，都可能把整个系统搞崩。
- 你正在用的生产环境是 Docker 容器或 Kubernetes 节点，容器里通常已经用非 root 用户运行进程了，宿主机 root 权限外泄会影响整个集群。
一句话总结：开发机和实验机启用 root 是效率刚需，生产环境和多人共用机器尽量别碰。 如果你只是觉得“书上说 Linux 就该用 root”，那建议再冷静一下。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 启用 root 用户的标准操作：从设置密码到正常切换
2.1 第一步：用 sudo passwd root 设置 root 密码
Ubuntu 默认虽然锁定了 root，但 root 账号本身是存在的，只是没有可用的密码。你只需要用当前用户身份，执行一条命令给它设置一个新密码，就完成了“启用”的第一步。在 Ubuntu 24.04 终端输入：
bash复制sudo passwd root
系统会先要求你输入当前用户的密码（sudo 验证），然后提示你设置新的 root 密码，并且会让你输两遍确认。这里有个细节要特别注意：passwd 命令在设置新密码时不会显示任何字符，也不要指望看到星号，这是终端的安全习惯，不是出了故障。
执行成功后你会看到 passwd: password updated successfully 这样的提示。从这一刻起，root 用户的密码锁就被解开了，你可以通过 su、su -、sudo -i 等命令切换过去。
需要说明的是，sudo passwd root 和 sudo -i 之后再执行 passwd 本质是一样的，都是修改 /etc/shadow 文件里 root 对应的密码哈希。但前者只需要一步，而且不会额外开启一个 root shell，操作更干净。
2.2 第二步：三种切换方式的区别和适用场景
启用 root 密码之后，切换方式有四种常见写法，我直接列个表格对比，方便你按需选择：
| 命令 | 是否加载 root 环境变量 | 是否读取 /root/.bashrc | 适用场景 |
|---|---|---|---|
su |
否，保留当前用户的环境变量 | 否 | 临时用一下 root 身份执行几条命令 |
su - |
是，完整切换到 root 登录环境 | 是 | 想进入一个干净的 root shell，路径、PATH、变量全切换到 root 的配置 |
sudo -i |
是，模拟 root 登录 | 是 | 当前用户拥有 sudo 权限时快速进入 root shell |
sudo bash |
部分，看 bash 启动方式 | 是 | 没有 root 密码但想用 root 权限跑脚本时 |
我个人的习惯是：临时执行一条特权命令用 sudo command；需要持续在 root 下操作或者测试脚本时，直接用 sudo -i，因为不需要额外输入 root 密码，而且能加载 /root/.bashrc 里的 alias 和 PATH，体验和真实 root 登录几乎一致。
如果你已经设置了 root 密码，想体验“正宗”的 root 登录流程，那就用 su -，它需要输入 root 密码，并且会把工作目录切到 /root，PATH 也切换成 root 的默认路径。这里有个新手经常踩的坑：在 root shell 里运行 vim 报“找不到命令”，其实不是 vim 没装，而是你的 PATH 里没有 /usr/sbin 或 /sbin 这些系统目录。用 su - 完整登录就不会有这个问题。
2.3 验证是否成功，以及常见报错的定位
设置完密码之后，你需要验证一下 root 是否真的能用了。最简单的验证方式是：
bash复制su - root
然后输入你刚设置的密码，如果一切正常，终端提示符会从 user@hostname:~$ 变成 root@hostname:~#，# 这个符号就代表你已经是超级用户了。
如果出现以下情况，说明某个环节有问题：
su: Authentication failure：说明你输入的 root 密码不对，或者根本没执行过sudo passwd root。su: Cannot open display：这不是 su 本身的问题，而是你尝试从图形界面程序里调用 su，X11 权限拦住了。Permission denied或Operation not permitted：大概率不是 su 的问题，而是你切换 root 之后执行的命令本身涉及文件权限或 AppArmor 限制。
验证完成后，如果你想重新禁用 root，方法也很简单，在 root shell 或 sudo 下执行：
bash复制sudo passwd -l root
这个命令会锁定 root 密码，效果等同于让它重新回到“无密码”状态。注意这个命令不会删除 root 用户，也不会把 /root 目录清掉，只是密码认证不可用，你依然可以通过 sudo -i 获得 root 权限。
3. 更进一步：直接以 root 身份登录图形界面或 SSH
很多人启用 root 不只是为了在终端里切换，还希望像 Windows 管理员账号一样，开机直接以 root 登录桌面，或者远程直接用 root 连 SSH。这部分操作在 Ubuntu 24.04 上比想象中麻烦，牵扯到显示管理器、PAM 模块、SSH 配置三个环节，少改一个你都成功不了。
3.1 在 tty 登录和 GDM 登录界面直接输 root 密码
如果你想要的是开机后在登录界面直接输入 root 用户名和密码进桌面，Ubuntu 24.04 默认的 GDM（GNOME Display Manager）默认是不允许 root 直接登录的。即使你设置了 root 密码，登录界面输 root 也会被 PAM 模块拦下来。
要放行这个限制，得修改 /etc/pam.d/gdm-password，把这一行注释掉：
bash复制auth required pam_succeed_if.so user != root quiet_success
操作步骤是：
bash复制sudo sed -i 's/auth required pam_succeed_if.so user != root quiet_success/#auth required pam_succeed_if.so user != root quiet_success/' /etc/pam.d/gdm-password
然后重启 GDM 或者整个系统。重启后登录界面点“未列出”，输入 root 和密码即可。
而 tty 登录（按 Ctrl+Alt+F2 切到纯命令行界面）则不受 GDM 这个限制，只要 root 密码存在，你就能在 tty 登录后输入 root 直接登录。不过 Ubuntu 24.04 的 login 程序也可能被 PAM 限制，如果遇到 Access denied，试着执行：
bash复制sudo passwd -u root
解锁一下 root 账号。
这里我特别提醒一句：让 root 直接进桌面是很危险的。 图形界面下垃圾软件装的 PAM 模块、输入法框架、网络管理器都可能以 root 权限自动运行，万一某个第三方软件在登录时执行了不安全的配置，危害远大于命令行 root。
3.2 配置 SSH 允许 root 远程登录的正确姿势
如果你想在局域网或公网上用 SSH 直接登 root，Ubuntu 24.04 默认的 sshd 配置是 PermitRootLogin prohibit-password，意思是允许 root 登录，但只允许通过密钥认证，不允许密码认证。
这已经是一个比较安全的默认值了，但对于不熟悉密钥配置的人来说，直接密码登录反而是最常用的。想改成密码登录 root，需要修改 /etc/ssh/sshd_config：
bash复制sudo vim /etc/ssh/sshd_config
找到 PermitRootLogin 这一行，改成：
bash复制PermitRootLogin yes
然后重启 sshd：
bash复制sudo systemctl restart sshd
如果你更讲究一点，可以只允许公钥登录，保持默认的 prohibit-password 不变，然后把自己的公钥放到 /root/.ssh/authorized_keys 里。这种方式对暴力破解的抵御能力远强于密码登录，我个人在云服务器上都会用这种方式。
顺带提一个与热搜词“error 1045 (28000): access denied for user 'root'@'localhost'”相关的问题：那虽然是你本机 MySQL 数据库的权限报错，但如果你的 Ubuntu 是开发环境，涉及数据库 root 登录时，这和系统 root 是两码事，别混在一起排查。MySQL/MariaDB 的 root 账号是单独一套权限体系，跟 Linux 系统 root 没有直接关系。
3.3 修改 PAM、GDM、SSH 配置文件时的注意点
修改 PAM 文件是 Linux 里非常“敏感”的操作，因为 PAM 控制着系统的认证流程，改错一行有可能导致任何人都无法登录。我给你的建议是：改之前先备份原文件。
bash复制sudo cp /etc/pam.d/gdm-password /etc/pam.d/gdm-password.bak
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
如果改出了毛病，可以切到 tty1（Ctrl+Alt+F1）用 root 或可登录用户进去，把备份文件恢复回来。千万别在 SSH 会话里改 sshd_config 之后立刻断开连接，一定要先重启 sshd，再另开一个会话尝试登录，确认没问题再关掉当前会话。否则万一配置写错，你连不上服务器就很被动了。
注意 Ubuntu 24.04 的 sshd 配置里 Include /etc/ssh/sshd_config.d/*.conf 这个机制依然存在，如果你在 /etc/ssh/sshd_config.d/ 下还有别的 .conf 文件，它们可能覆盖 /etc/ssh/sshd_config 里的设置。排查时别只盯着主配置，ls /etc/ssh/sshd_config.d/ 看看有没有自定义配置。
4. 启用 root 之后的权限边界与安全加固
4.1 root 不是万能药：目录权限、AppArmor 仍然挡着你
很多刚接触 Linux 的人有个误区：root 拥有绝对权限，所有操作都可以为所欲为。但实际上，root 只是绕过了传统的 Unix 权限检查，并没有绕开文件属性、安全模块和文件系统特性。
举例来说，如果文件被设置了 chattr +i（不可变标志），即使是 root 也不能修改或删除它，只能先执行 chattr -i 解除标志。我在给某些系统加固脚本添加关键文件保护时就会用这个特性。
Ubuntu 24.04 默认启用了 AppArmor，这是一个内核级安全模块，很多系统服务（比如 Docker、MySQL、Redis）都有对应的 AppArmor 配置文件。root 用户虽然能修改文件，但不能绕过 AppArmor 策略，除非你先 aa-complain 或者卸载相关 profile。所以你会遇到一种诡异的情况：明明以 root 身份执行了 /etc/init.d/mysql start，但 MySQL 还是报权限错误，最后发现是 AppArmor 限制了它对 /data/mysql 目录的访问。
4.2 给 root 设置一个足够安全的密码
既然要启用 root，就不要再设置一个像 123456、root、password 这种弱密码，否则让暴力破解工具跑几百秒就完蛋了。一个安全密码至少要满足：
- 长度不低于 14 位
- 包含大小写字母、数字、特殊符号
- 不要跟用户名、主机名、任何常见单词直接相关
- 不要和 sudo 组的普通用户密码相同
Ubuntu 24.04 的 passwd 工具默认已经启用了密码强度检查（libpam-pwquality），太简单的密码会被直接拒绝，这是好事。你可以使用组合词加特殊符号的方式，比如 BlueBird-2024-up! 这种，既好记又不容易被字典攻击碰到。
如果你实在记不住这么复杂的密码，那就把 root 的登录方式限制为“仅本机切换 + SSH 公钥登录”，这样即使密码强度稍弱，也不至于直接从网络被攻破。
4.3 建议保留 sudo 并创建日常用户，root 仅用于特殊运维
启用 root 不代表你从此就要抛弃 sudo。我强烈建议你在系统里保留一个普通用户，日常开发、浏览网页、运行 IDE 都用普通用户，只有在做系统级配置时才切换到 root。这样做的原因是：
- 图形界面应用在 root 下运行时，容易出现奇怪的故障。比如浏览器沙箱、输入法框架、音频服务，都可能因为权限过高而拒绝工作。
- 很多现代开发工具（VS Code、Docker）默认尝试以非 root 身份运行，root 反而会触发各种权限检查限制。
- 万一普通用户被攻破，攻击者还要再破解一次密码才能获得 root 权限，多一层防线。
Ubuntu 24.04 安装时创建的初始用户本来就在 sudo 组里，日常用 sudo 足够了。root 账号我一般只用于清理系统残留、修改 /etc 下复杂配置、处理启动引导这类需要深度介入的场景。
4.4 AppArmor、SSH、fail2ban 等加固建议
如果你把 root 启用在能被外部访问的服务器上，那么安全加固就是必修课：
- SSH 端选择非默认端口。Ubuntu 24.04 默认的 sshd 端口是 22，公网上每天有大量扫描器在尝试爆破，把
Port改成一个高位端口能挡掉 90% 的自动化攻击。 - 公钥认证优先，密码认证作为后备。使用
ssh-keygen生成密钥对，把公钥放到 root 的 authorized_keys，然后设置PasswordAuthentication no。 - 安装并配置 fail2ban。它会监测
/var/log/auth.log，对连续登录失败的 IP 自动添加防火墙封禁规则。Ubuntu 24.04 上可以用apt install fail2ban安装，默认配置对此场景基本够用。 - 如果不用 SSH 远程管理，直接
systemctl disable --now sshd把它关掉。
这套组合下来，root 密码即使泄露，攻击者想进来也没有那么容易。千万别觉得自己只是台虚拟机，攻击者根本没兴趣——实际上扫描器根本不区分你是谁，只要是公网 IP 就无差别扫描。
5. 我在虚拟机和真实服务器上启用的实测经验与避坑记录
5.1 VMware 里 VMware Tools、共享文件夹的 root 权限坑
我用 VMware Workstation 装 Ubuntu 24.04 的时候，习惯上会先把 root 启用，因为要频繁改系统配置、测试初始化脚本。但有个坑跟 root 直接相关：VMware 的共享文件夹（hgfs）挂载点默认权限属于 root 和 vmware 组，普通用户访问共享目录经常碰到 Permission denied。
在 VMware Workstation 里设置共享文件夹后，它通常会自动挂载到 /mnt/hgfs/，但客户端访问权限取决于你在虚拟机里怎么配置挂载选项。如果你以 root 身份创建了 /mnt/hgfs 下的某些目录，普通用户就没有写权限。解决办法是重新挂载时加上 uid/gid 参数，例如：
bash复制sudo vmhgfs-fuse -o uid=1000,gid=1000 .host:/shared /mnt/hgfs/shared -o allow_other -o nonempty
这里 uid=1000 是初始普通用户的 UID。如果你一直用 root 操作，/etc/fstab 里的挂载配置如果写的不带 uid/gid，就会导致普通用户看着这个目录却没法读写——非常典型的“root 启用了但日常使用很痛苦”场景。
另外，VMware Tools 的两个服务（vmware-tools.services、vmware-tools-thinprint.services）在 root 环境下偶尔会报错，尽量不要手动去改它们的权限，保持默认就好。这类错误一般不会影响系统运行，不用太纠结。
5.2 root 环境下 Docker、显卡驱动、输入法这类高频操作的表现
Ubuntu 24.04 上安装了 Docker 之后，如果你直接以 root 身份运行 docker ps 通常没问题，因为 Docker CLI 本身需要 root 权限。但如果你以普通用户运行，没加 docker 组就会遇到权限报错。启用 root 之后很多人直接把 docker 组忘掉了，这其实不太合理——更安全的方式是把普通用户加入 docker 组，而不是用 root 跑 Docker。
NVIDIA 显卡驱动的安装，在 Ubuntu 24.04 上推荐用 ubuntu-drivers install 或者附加驱动仓库，这个过程经常需要 root 权限。很多人在这一步直接用 root 登录桌面再装驱动，结果发现 X 服务在 root 下启动有问题。我自己遇到过的情况是：root 下用 ubuntu-drivers autoinstall 装完驱动，重启后图形界面起不来，最后发现是 GDM 的 Wayland 会话和 root 不兼容，还得切到 tty 登录改回 Xorg 会话。
搜狗输入法、中文输入法在 Ubuntu 里的安装配置也需要写系统级目录，但要注意输入法框架（fcitx5/ibus）一般不应该在 root 桌面会话里运行。root 登录桌面后输入法经常无法调出，因为输入法进程的 session 权限和普通用户的 dbus 配置对不上。所以如果你日常要用输入法，建议别直接用 root 桌面。
5.3 误操作导致系统无法启动时怎么恢复
启用 root 后，新手最容易翻车的就是修改系统关键文件时权限太顺手，一不小心写坏了 /etc/fstab 或者 /etc/sudoers，然后系统起不来或者 sudo 全挂。这里给你一个我的救命流程：
- 启动时在 GRUB 菜单（如果有）选择“Advanced options for Ubuntu”，然后选“recovery mode”。
- 在 recovery menu 里选“root - Drop to root shell prompt”，系统会给你一个只读文件系统的 root shell。
- 先执行
mount -o remount,rw /让根文件系统可写。 - 然后修改之前写坏的文件，或者恢复备份。
- 执行
reboot重启。
如果你 GRUB 里没有 recovery mode 选项，也可以在启动时按 e 编辑内核启动参数，在 linux 那一行末尾加上 init=/bin/bash，然后按 Ctrl+X 启动，同样会进入一个 root shell。但这种方式没有挂载太多文件系统，很多工具用不了，需要手动挂载和修复。
我自己实测过几次，最常被改坏的其实是 /etc/sudoers——因为启用 root 之后，很多人想顺便收回普通用户的 sudo 权限，结果语法写错，普通用户和 root 都进不去。这个情况下，恢复模式里的 root shell 就是你最后的救命稻草。进去之后用 visudo 修正语法，或者直接改成 user ALL=(ALL) ALL 恢复默认。
5.4 关于“永久禁用 root”的正确姿势
既然讲了怎么启用，也顺便说说怎么彻底禁用。在 Ubuntu 24.04 上，如果你确认不再需要 root 密码登录，想回到默认的安全状态：
bash复制sudo passwd -l root
sudo usermod --expiredate 1 root
第一条锁定密码，第二条立即让 root 密码过期，效果是 root 无法通过密码登录，包括 su 和 SSH。如果之后临时想用 root，在 sudo 组用户下执行 sudo passwd -u root 可以解锁。
如果你连 root 账号都希望“不存在”，那需要编辑 /etc/passwd，但这会破坏很多系统工具对 root 的依赖，我极其不建议这么干，不要为了追求安全把根基拆了。
根据我自己的使用习惯，启用 root 后的最佳状态是：日常生活在普通用户，需要临时提升权限用 sudo，需要长期进入特权环境用 sudo -i，只有实验或运维需要才用 root 密码直接登录。 这样既保留了 Ubuntu 原本的安全设计，也不会让 sudo 密码频繁输入打断你的流程。最后提醒一句，sudo passwd root 设密码时记得起一个你会在半年后还能想起来的强密码，不然真到应急时进不去 root，会更头疼。