企业官网建设流程全解析

桌面版和服务器版Ubuntu用多了，你一定遇到过这样的矛盾：装好系统之后，平时用sudo完全可以管理机器，但真正需要以root身份登录图形界面、做SSH远程维护或者跑某些自动化脚本时，系统却始终不给root“开门”。这篇文章就把Ubuntu启用root账号并登录这件事从头到尾拆开讲，覆盖了桌面版本地登录、服务器版SSH登录、忘记密码后的救援恢复，以及各种常见的报错和误判场景。我会把实际操作步骤、踩过的坑和排查思路都写出来，无论你是在虚拟机里试验，还是在真实服务器上配置，都能直接照着做。

1. Ubuntu默认锁死root，这层设计到底想干什么

先解决一个最基础的问题：Ubuntu不是不能登录root，而是安装过程中故意不设root密码，把超级权限全部交给sudo机制。你刚装完系统后，在终端里执行su，大概率会看到Authentication failure，而执行sudo -i却能顺利拿到root shell。这不是系统坏了，而是Ubuntu从桌面发行版理念出发做的刻意设计——让普通用户日常使用普通账号，需要特权时通过sudo临时提权，这样系统日志里每一条高危操作都能记录到具体是哪个用户执行，出了问题也能追踪。

这个设计和RedHat/CentOS那种“安装时直接设置root密码、安装完就能登录root”的路径完全不同。对新手来说，sudo机制确实更安全：你不用记住一个单独的root密码，误操作root权限的概率也小。但对老手来说，有些场景真的绕不开root身份。举几个我实际遇到的情况：

• 在图形界面环境下，某些老旧或者特殊的安装程序、开发工具要求直接用root运行，参数和行为会有差异；
• 服务器上要临时给其他同事开放root登录，或者要做一次性的远程维护；
• 接手的服务器是一台云主机、物理机或者迁移过来的系统，只知道普通用户密码，但需要拿到root做系统初始化；
• 自动化脚本、CI/CD流程里需要借助SSH的root权限执行命令，而sudo免密配置在某些环境里并不生效。

所以，启用root并不代表“放弃安全”，而是需要按场景分情况处理。文章后面我给的步骤和建议，也会区分“桌面测试环境”和“生产服务器”两种场景。核心原则是：能用sudo的时候不要开root，必须要开的时候，把登录方式、密码策略和SSH配置分开管控。

我见过很多人在网上搜到一篇“即时启用root”的文章，直接复制命令改了root密码，结果把云主机的SSH登录卡住了，或者图形界面登录不上，最后只能从头重装。原因往往是把几个配置文件搞混，或者忽略了Ubuntu不同版本、不同镜像（桌面版、Server版、云镜像）之间的默认配置差异。下面几节就是针对这些场景的完整操作。

2. 首次启用root：从设置密码到本地登录的全过程

2.1 设置root密码时的正确操作

启用root的第一步，也是最关键的一步，是给root设置一个有效密码。这个操作本身不复杂，但有几个细节容易翻车。

先用一个有sudo权限的普通用户登录系统，打开终端，执行：

sudo passwd root

系统会先要求输入当前普通用户的密码，这一步校验的是sudo权限；随后会出现New password:和Retype new password:，这时候输入的才是root的新密码。很多人在这里会犯一个低级错误：以为第一步输的是root密码，结果顺手输入两遍普通用户密码，然后就会在后续登录root时一直提示su: Authentication failure。

设置密码时需要注意的点包括：

• 密码尽量用字母大小写加数字加符号的组合，长度不低于12位。root权限一旦被爆破，后果比普通用户被爆破严重得多。
• 输入的密码在终端里不会显示任何字符，连星号都没有，这是正常现象，不要以为按键没生效。
• 确认密码时如果两次输入不一致，系统会提示Password unchanged之类的信息，需要重新执行一次。
• 如果提示su: 鉴定令牌操作错误，一般是PAM模块的写入有问题，或者密码没设置成功，重新执行一次往往就好了。

设置成功后会显示passwd: password updated successfully，这时候root密码状态就已经打开了。但是，这仅仅代表root账号“有密码了”，不代表你就能马上在图形登录界面或SSH里登录root，接下来还有好几道门槛要过。

2.2 在图形登录界面允许root登录

如果你用的是Ubuntu桌面版（GNOME桌面），设置完root密码后，按说可以直接在登录界面选择“Not listed”或者“其他用户”，输入用户名root和刚才设置的密码。但实际测试中经常遇到的情况是：密码明明正确，回车之后屏幕却闪烁一下，又回到登录界面，没有任何错误提示。这个现象多数不是密码问题，而是GDM登录管理器在PAM层直接把root拒了。

Ubuntu桌面版的GDM默认配置里，/etc/pam.d/gdm-password这个文件包含一行：

auth required pam_succeed_if.so user != root quiet_success

翻译成人话：只要登录的用户是root，就直接认证失败并静默返回。要允许root从图形界面登录，需要把这行注释或删除。可以这样操作：

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服务，或者直接重启系统。注意重启GDM会导致当前桌面会话全部退出，所以最好在终端里做好保存工作再操作。

还有一个细节：修改完PAM配置后，如果登录界面还是无法用root登录，可以按Ctrl+Alt+F3切换到纯文本TTY终端，在TTY里输root用户名和密码。TTY登录走的是login的PAM配置，和图形界面的PAM不是一套，很多时候TTY是能登录的，但图形界面不行。这也可以反过来验证一下密码是否正确，避免被GDM的问题误导。

顺带提一下，有些老教程会让你修改/etc/pam.d/login或者/etc/pam.d/su，那是为了解决“su切换root受限制”的问题，不是图形登录的问题，方向别搞混。

2.3 桌面环境使用root的小心机

root从图形界面登录进去之后会发现，有些桌面功能表现得很奇怪。比如GNOME桌面下，很多系统对话框、文件管理器、应用商店可能无法正常启动，或者打开软件时提示“无法以root身份运行”。这是GNOME有意限制root使用图形应用的一部分，尤其是新版Ubuntu。如果你只是想在图形界面里以root身份做一两个操作，我不建议长期用root桌面，而是保留普通用户桌面，需要用root时再打开终端执行任务。

我自己踩过的一个典型案例是：用root登录GNOME后，想用自带文件管理器去挂载一个移动硬盘，结果文件管理器直接整个崩溃。后来发现是root的/root/.config目录权限或者某些模块不兼容。临时解决办法是用命令行的mount命令挂载，或者用gksu类工具（现在已经从默认源里移除了）再试试。这里给普通桌面用户一个明确的建议：图形界面日常操作留在普通账号里，真正需要root时用终端。

3. 通过SSH远程登录root：服务器场景的完整配置

3.1 修改sshd配置并重启服务

服务器版的Ubuntu默认也不允许root通过SSH登录。这时候你即使给root设置了密码，远程用ssh root@服务器IP去连，也会得到Permission denied, please try again.的提示。这时候需要调整OpenSSH服务端的配置。

配置文件是/etc/ssh/sshd_config。早期版本的Ubuntu直接改这个文件里的PermitRootLogin行就行，新版本（比如22.04和24.04）则要注意，默认的sshd_config里存在Include /etc/ssh/sshd_config.d/*.conf这样的包含配置，云镜像经常用drop-in目录来覆盖主配置。如果你只改了主配置文件，但drop-in目录里有个60-cloudimg-settings.conf写着PermitRootLogin no，最终生效的依然是不允许登录。很多人在这一步踩坑之后，怎么重启SSH都没用，最后检查半天才发现是drop-in文件优先级更高。

操作步骤：

sudo nano /etc/ssh/sshd_config # 找到或者新增一行 PermitRootLogin yes

如果主配置文件里没有PermitRootLogin这一行，直接新增即可。如果你想保留drop-in目录，也可以在/etc/ssh/sshd_config.d/下新建一个文件，比如99-root-login.conf，里面写入：

PermitRootLogin yes

由于Include是按文件名顺序加载的，99-开头的文件比默认配置的加载顺序靠后，能覆盖前面的设置。

修改完成后，先校验配置语法：

sudo sshd -t

如果这条命令没有输出，说明语法没问题；接着重启SSH服务让它生效：

sudo systemctl restart ssh

重启后从目标机器或者客户端试一下：

ssh root@服务器IP

输入root密码，如果能正常登录，说明已经通了。如果还是被拒绝，按下面章节的排查思路逐条检查。

3.2 root用户使用密钥登录与密码登录的差异化配置

SSH登录root其实有两种常用方式：密码登录和密钥登录。生产环境我更推荐密钥登录，因为密码登录一旦被暴力扫描，风险很高。但在内网、虚拟机、临时调试环境里，密码登录图方便也无可厚非。

密钥登录的配置只需要把客户端的公钥追加到root用户家目录的/root/.ssh/authorized_keys文件里，然后在sshd_config里设置：

PermitRootLogin prohibit-password

prohibit-password的意思是：允许root登录，但只允许密钥方式，不允许密码方式。这个值比yes更安全，如果你既需要root远程登录，又担心里面装一个带密码的SSH会暴露风险，那就用这个配置。注意prohibit-password是OpenSSH 7.0以后的新写法，旧版本里对应的值是without-password，Ubuntu 20.04以上都不用担心这个问题。

实际操作中，我建议把密码认证和root登录的开关分开理解：PasswordAuthentication yes/no控制的是所有人能不能用密码登录，PermitRootLogin控制的是root能不能登录。不要误以为把PermitRootLogin yes改掉，就等于禁止了所有人SSH登录。如果你只希望普通用户可以通过密钥或密码登录、root不允许，那就要保持PermitRootLogin no；如果希望普通用户密码登录、root仅密钥登录，那就用PermitRootLogin prohibit-password。

3.3 改完SSH配置后验证和排错

修改SSH配置最怕的是直接把自己锁在门外。我常用的做法是不要关闭当前SSH连接，再新开一个终端窗口测试新的登录方式，确认能连上之后再考虑关闭旧连接。这个习惯在远程服务器上救过我很多次。

改完后可以用下面的命令看当前SSH服务端的实际参数：

sudo sshd -T | grep -i permitrootlogin sudo sshd -T | grep -i passwordauthentication

sshd -T会显示加载全部配置后的实际运行参数。如果你发现改的文件和sshd -T输出的结果对不上，那几乎可以肯定是drop-in配置文件优先级问题，别继续折腾主配置了，老老实实检查/etc/ssh/sshd_config.d/下的内容。

另一个排错姿势是看SSH日志：

sudo journalctl -u ssh --no-pager -n 50

日志里如果出现Failed password for root但密码你没输错，那多半是sshd配置里禁止root密码登录，或者是PasswordAuthentication被设成了no。如果日志里显示User root from 192.168.1.10 not allowed because not listed in AllowUsers，那就说明系统里有AllowUsers限制，需要把root加进去，或者删除限制。

4. 忘记root密码也别慌：恢复模式和救援挂载实战

4.1 从GRUB进入恢复模式重置密码

启用root后，最尴尬的一种情况是：root密码忘了，普通用户又因为各种原因进不去系统（比如忘了普通用户密码，或者sudo配置被改坏）。这种情况也不是死局，只要你有服务器控制台或物理机键盘，就能通过GRUB引导进入恢复模式。

重启机器，在GRUB菜单出现时按下Shift键（如果是UEFI启动，可能需要多次按Esc或其他键，视具体引导程序而定）。在Ubuntu的引导条目上按e键进入编辑模式，找到以linux开头的行，通常在末尾有ro quiet splash之类的参数。把这几个参数改掉，替换为：

rw single init=/bin/bash

注意把ro改成rw是为了让根文件系统直接以可写方式挂载。改完按Ctrl+X或者F10启动，系统会直接进入一个root shell。此时不需要任何密码就能拿到root权限。

在shell里执行：

mount -o remount,rw / passwd root

输入新的root密码，然后重启：

reboot -f

这种方法在物理机和虚拟机里都很好用。但要特别提醒：如果你启用了磁盘加密（LUKS），情况会复杂一些——GRUB引导时系统会先要求输入加密密码解密磁盘，之后才会进入initramfs环境。没有加密密码的话，这条路就行不通了。

4.2 根文件系统只读问题的处理

用rw single init=/bin/bash启动后，大多数情况下根文件系统是可写的。但某些较新版本的Ubuntu（特别是采用某些云镜像或者特殊initramfs配置的系统）在进入initramfs时可能仍会把根挂载为只读。遇到这种情况，在root shell里先检查：

mount | grep ' / '

如果输出里带着ro，就先重新挂载：

mount -o remount,rw /

然后再执行passwd root。如果你需要修改的文件位于/usr、/etc等子目录，但根挂载是只读的，任何写入操作都会报Read-only file system。这个报错我在调试时见过太多次了，很多人以为系统崩溃了，其实只是没重新挂载而已。

如果整个根文件系统因为之前的异常关机需要检查和修复，可以在恢复模式下先执行：

fsck -y /dev/你的根分区

这个操作有可能修复文件系统索引，但也有可能丢数据，所以非必要不主动跑fsck，尤其是在生产环境。

4.3 通过恢复模式重构root登录条件

恢复模式不仅能改root密码，还能顺带修复很多和root登录相关的配置文件。比如你之前把sshd_config改坏了导致SSH起不来，可以在恢复模式shell里直接改回来；把/etc/pam.d/gdm-password改错导致图形登录不了，也可以在恢复模式下还原。

我印象很深的一次经历是帮朋友救一台Ubuntu 22.04桌面机，他在尝试启用root登录时手滑把/etc/passwd里的root行改坏了，导致重启后所有用户都登录不上。我用启动盘进入live环境后，挂载硬盘、chroot进去、修正了passwd文件，然后修改root的shell为/bin/bash，最后再让系统正常启动，问题迎刃而解。恢复模式提供的这个root shell就是应急修复的生命线，平时不用刻意记太多，知道思路就好。

5. 高频报错速查：这些提示真不是root权限有问题

在实际操作过程中，很多人会被一些看似和“root登录”有关的报错带进死胡同。我挑了几个出现频率最高的错误，按真实原因和解决方向整理成一个速查表，方便你对着排。

这里把MySQL/MariaDB的问题单独拿出来说一句，因为我在网上看到太多人把数据库root和系统root搞混。error 1045 (28000): access denied for user 'root'@'localhost' (using password: YES)是数据库认证失败，跟你改不改系统root密码没有任何关系。碰到这种报错，进入数据库的方式是：

sudo mysql -u root

或者：

sudo mariadb

然后在数据库里重新设置root密码，或者直接创建专用数据库账号来用。我见过有人为了这个数据库报错，用恢复模式去改/etc/shadow，白折腾一圈还差点把系统弄坏。

另一个经常出现的误解是：普通用户执行sudo -i后，再用echo $USER看到的不再是当前用户名，这种情况下很多人以为已经是root了，但这和系统登录root是两回事。sudo -i拿到的是一个root shell，但它依赖的是当前普通用户的sudo权限，一旦sudo配置失效，这个shell也就拿不到了。真正要“以root身份登录系统”，要么用su -，要么在登录界面或SSH里直接输root账号。两者的使用边界要清楚。

6. 启用root之后，建议把这几个习惯固定下来

启用root登录不是装完就完事，后续使用上有几个习惯值得尽快养成。我按自己的实践经验整理了几条，没有空话，每一条都是踩过坑换来的。

第一，生产服务器上尽量不要开PermitRootLogin yes的密码登录。如果非要开root SSH，优先用密钥认证。运维上可以把普通用户加入sudo组，日常用普通用户登录，再sudo -i提权；只有自动化任务或特殊维护才走root密钥登录。这样即使普通账号被入侵，攻击者拿到的也只是普通用户权限，而不是一上来就是root。

第二，桌面电脑的root密码别和普通用户密码设成一样的。很多人图省事设成相同密码，结果一个密码泄露就等于失去了所有防线。给root单独设一个复杂密码，写在密码管理器里而不是记事本里。

第三，修改任何系统关键配置前，先备份。比如要改/etc/ssh/sshd_config，可以先执行：

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)

这样即使改错了，也能快速还原。修改完先sshd -t验证，再重启服务，能避免很多自锁门的情况。

第四，如果只是在单机上临时想体验root权限，用sudo -i就可以，没必要去开图形登录root。图形界面用root带来的问题远多于收益，桌面应用的权限隔离和root的全局权限本身就有很多冲突。

第五，定期检查系统日志里有没有异常root登录记录。可以看这几个文件：

sudo tail -n 50 /var/log/auth.log sudo journalctl -u ssh --no-pager -n 50

如果发现自己并没有在这些时段登录过，但日志里有root登录记录，要立刻排查是不是密码被泄露了，顺便把root密码改掉，并且把SSH端口做一下限制。

从我个人经验来说，启用root账号最安全的用法其实是“平时不用，用时再开”。服务器上明明可以用普通用户完成的事，就不要让root常驻；一旦把root的密码和登录方式暴露在网络里，它就是一台机器最重要的攻击面。所以这篇文章教你的不只是怎么把root打开，更重要的是告诉你打开之后哪些地方是坑、哪些做法能让你睡得着觉。