Flutter适配OpenHarmony踩坑实录：从环境到打包的完整排查指南
2026/9/30 3:30:24
简介：一份针对Ubuntu 20.04系统的PDF运维操作指南，专门解决默认禁用root账户登录的问题，适合需要直接以root身份进行系统管理或高权限操作的Linux用户。资料以步骤化方式完整梳理了开启root并实现手动登录的全过程，包括利用sudo passwd root设置密码，修改lightdm配置文件添加手动登录选项，在PAM认证文件中注释限制root的相关行，以及调整/root/.profile以兼容终端消息等关键操作，每一步都附有明确命令和易错点提醒。资源包仅含1个PDF文件，大小1.97MB，轻量易用，目前已吸引4026人浏览学习。通过这份指南，读者可以系统掌握Ubuntu 20.04启用root账户的配置思路与具体命令，同时理解相关配置文件的作用，避免盲目修改引发图形界面登录异常，对日常运维、实验环境搭建或教学演示均具实用价值。
1. 开启 root 账户：你需要的不是权限，是 Ubuntu 的默认约定
Ubuntu 20.04 的 root 账户默认是锁定的，这在很多刚从 CentOS 或 Windows 换过来的人眼里像个玄学：明明 sudo -i 可以拿到 root 权限，偏偏 su 一敲就报su: Authentication failure。问题不在密码，而在 Ubuntu 故意不给 root 设密码——安装时创建的用户是被放进 sudo 组的，日常管理走 sudo 授权，root 账户直接封存。本篇就把这条路走通：从给 root 设置密码、切到 root，到配置 SSH 和图形界面登录，最后是忘记密码后的恢复流程。适合系统运维、嵌入式开发调试，以及任何想把 Ubuntu 20.04 当成服务器或开发主力机的人。
2. 从 sudo 到 root：给 root 设置密码与切换的最小操作
开启 root 账户的标准路径是“先通过 sudo 修改 root 的密码，再用 su 切换”，不是直接去改/etc/shadow里的密码哈希，也不是把普通用户的 UID 改成 0。下面按依赖关系一步步拆。
2.1 为什么先有 sudo 才能动 root
Ubuntu 20.04 安装时创建的第一个用户默认属于sudo组，这个组在/etc/sudoers里有完整授权：
%sudo ALL=(ALL:ALL) ALL意思是 sudo 组的成员可以把任何命令以任何用户身份执行。而 root 账户初始状态在/etc/shadow里是锁定的，最典型的标志是密码字段不是哈希串，而是!或*，例如：
root:!:19000:0:99999:7:::这个!表示账户没有可用密码，任何密码验证都会被拒绝。你敲su root时系统去读这个字段，发现不是合法哈希，直接返回认证失败，跟密码对不对无关。
所以“开启 root 账户”的第一步，是让这个字段从!变成一串密码哈希。而能改写/etc/shadow的只有 root，普通用户要借助 sudo 提升权限。这也是整个流程绕不开 sudo 的原因。
先确认当前用户具备 sudo 资格：
groups sudo -lgroups查看当前用户所在组，sudo -l查看当前用户可执行的命令列表。输出里能看到(root) ALL之类的内容，就说明 sudo 路径是通的。
2.2 设置 root 密码：一条命令与它的前置条件
执行下面这条命令，用 sudo 提权给 root 设置新密码：
sudo passwd root命令执行后系统提示New password:，输入两次相同密码。看到passwd: password updated successfully才算成功。这一步同时做了三件事：解开/etc/shadow里的锁定标记、写入密码哈希、设置密码过期日期。
这里的先后顺序不能错。有些人直接敲passwd root，结果提示passwd: You may not view or modify password information for root.，原因就是普通用户没有对 root 的 shadow 条目写入权限。sudo passwd root则是把整个操作放到 root 上下文里执行，权限足够，也能正确刷新缓存。
还有一个前置条件值得单独检查：如果当前用户不在 sudo 组，sudo会提示user is not in the sudoers file。这时可以重启进入恢复模式，或者用另一个有 sudo 权限的账户执行：
sudo usermod -aG sudo 用户名2.3 切换与验证：su、su - 和 sudo -i 用哪一个
密码设置成功之后，切到 root 有三种常见方式，区别在于环境影响变量和认证来源：
| 命令 | 认证方式 | 进入后的环境 | 典型行为 |
|---|---|---|---|
su root | root 密码 | 保留当前用户的环境变量 | PATH 里可能没有/sbin，systemctl找不到 |
su - root | root 密码 | 重新读取 root 的登录环境 | 相当于 root 重新登录一次，PATH 完整 |
sudo -i | 当前用户密码 | 以 root 身份加载 root 环境变量 | 不要求 root 密码，只要求当前用户在 sudo 组 |
日常排查系统问题时，su -和sudo -i更可靠。举个最常见的翻车现场：su root进去执行systemctl status nginx，提示bash: systemctl: command not found，因为普通用户的 PATH 里没有/usr/bin/systemctl对应的目录。su - root会重新加载/root/.profile，把/usr/sbin:/sbin加回 PATH，命令就正常了。
验证是否真的切到了 root，不要看命令提示符里那个#，用身份查询命令：
whoami id -uwhoami输出root，id -u输出0，才算真正拿到了 root 身份。id -u返回 0 比提示符更可信，因为 shell 提示符可以被 PS1 环境变量伪造。
到这里，“开启 root 账户”的最小闭环已经完成：设置密码、切换、验证。下面两章解决的是扩展场景：怎么让 root 能远程登录，以及哪些改动会把你带进坑里。
3. 让 root 能远程登录：SSH 与桌面登录的配置改动
在 Ubuntu 20.04 桌面版上，单纯设置 root 密码后，SSH 默认还是拒绝 root 登录，图形界面登录时也会直接弹回。原因不一样，改动的地方也不一样。
3.1 PermitRootLogin 参数说明：三个值和一种推荐写法
SSH 服务由sshd_config控制，Ubuntu 20.04 里默认配置是PermitRootLogin prohibit-password，含义是“root 不能用密码登录，但可以用公钥登录”。做开发调试的人往往想直接用密码登录，改起来其实只有一行：
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo nano /etc/ssh/sshd_config在文件里找到#PermitRootLogin prohibit-password，去掉注释，改成PermitRootLogin yes。改完之后重启服务：
sudo systemctl restart ssh重启后不要急着断开当前 SSH 会话，先在另一个终端窗口验证配置是否被正确加载：
sshd -T | grep -i permitrootlogin输出permitrootlogin yes就说明改进去了。
这里有个细节：/etc/ssh/sshd_config文件开头有一行Include /etc/ssh/sshd_config.d/*.conf，Ubuntu 20.04 打包服务时会在/etc/ssh/sshd_config.d/里放配置文件，目录内文件比主配置文件里的同名参数优先级更高。如果你改了主文件没生效，先去看目录里有没有覆盖配置。更稳妥的做法是直接在目录下建一个独立文件：
sudo nano /etc/ssh/sshd_config.d/99-root.conf写入内容：
PermitRootLogin yes这样版本升级时也不容易被默认配置覆盖。对应参数的可选值有三个，按风险从高到低排列：
| 参数值 | 行为 | 适用场景 |
|---|---|---|
no | 禁止 root 登录 | 生产服务器，安全要求高 |
prohibit-password | root 可用公钥登录，密码登录禁止 | Ubuntu 默认值，适合已配置密钥的场景 |
yes | root 可密码或公钥登录 | 本地调试、内网测试机、临时排查 |
如果打算长期开 root 的 SSH，推荐prohibit-password配合公钥认证，而不是yes。用公钥登录需要先把公钥推上去：
ssh-copy-id root@服务器地址公钥认证绕开了密码猜测，root 密码本身泄露的风险也跟着下降。改完参数后，检查 SSH 服务状态：
sudo systemctl status ssh确认没有报Permission denied或语法错误。常见语法错误是参数名拼错或值写错，在sshd -t阶段就能暴露，所以每次改完先跑一下sudo sshd -t，再重启服务。
3.2 桌面环境（GDM）允许 root 登录的调整
桌面版 Ubuntu 20.04 默认用 GDM 作为显示管理器，GDM 通过 PAM 模块对登录做二次校验，其中有一行规则限制了 root：
sudo nano /etc/pam.d/gdm-password文件里有这样一行：
auth required pam_succeed_if.so user != root quiet_success这行的意思是“如果用户不是 root，认证静默通过；用户是 root，认证失败”。要让 root 在图形界面登录，把这行注释掉：
# auth required pam_succeed_if.so user != root quiet_success保存退出后重启 GDM 才会生效：
sudo systemctl restart gdm3注意：重启 GDM 会终止当前桌面会话，所有未保存的桌面应用内容都可能丢。实际操作前先保存工作，或者安排在没有图形任务的窗口期。改完 PAM 后，在登录界面选择“Not listed?”输入root和密码即可登录。
如果你的 Ubuntu 20.04 用的不是 GDM 而是 LightDM，对应文件是/etc/pam.d/lightdm，配置结构相近，找user != root那一行同样处理。判断当前登录管理器可以用cat /etc/X11/default-display-manager，输出/usr/sbin/gdm3就是 GDM，/usr/sbin/lightdm就是 LightDM。
不推荐长期用图形界面登录 root。桌面环境里运行的 GTK 应用、浏览器、文件管理器都带着 root 权限，一旦被漏洞利用就是整个系统沦陷。我更建议桌面机保留普通用户登录，root 只通过 SSH 或终端使用，两边环境互不干扰。
3.3 改动后的验证与回滚
每次配置改动后，按下面顺序确认状态：
sudo sshd -t sudo systemctl restart ssh sshd -T | grep -i permitrootloginsshd -t只检查语法，不加载网络服务，适合做快速自检。sshd -T输出的是最终生效配置，比直接读配置文件可信，因为它把sshd_config.d里的覆盖关系也处理完了。
如果配置改坏了，最直接的后悔药是把备份恢复回去：
sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config sudo systemctl restart sshPAM 那边的回滚同样简单：把注释掉的那行重新取消注释，重启 GDM。
有一个改动顺序上的习惯值得坚持：所有涉及登录认证的配置，修改前先开一个不需要验证的会话。比如先确认自己能以普通用户 SSH 登录，再改 root 登录配置，这样即使配置写错，还能用普通用户会话进去修复，不至于把自己锁在门外。
4. 开启 root 的避坑记录：四个高频翻车现场
以下都是从实际运维里看到的踩坑清单，每一条都按“现象、原因、解决”来写。这些问题不会同时出现，但遇到任何一个都能耽误半天。
4.1 su: 鉴定令牌操作错误，密码明明没错
现象：设置完 root 密码后执行su root，提示su: 鉴定令牌操作错误或su: Authentication failure，并且无论如何重新输入密码都没用。
原因：绝大多数情况下，sudo passwd root并没有真正执行成功。几种典型情况：命令敲成passwd root导致没有写权限；sudo输错密码取消执行；或者命令在系统提示更新密码后才看到“updated successfully”，实际上更新的是当前用户而不是 root。另一种原因是 root 密码字段里有特殊字符，在 shell 里输密码时被终端转义，这个概率低一些。
解决：先确认 root 账户在/etc/shadow里的状态：
sudo grep '^root:' /etc/shadow正常解锁状态是root:$6$...，以$6$或$y$开头的哈希串。如果看到root:!或root:*，说明密码没写进去。重新执行：
sudo -i passwd rootsudo -i直接切到 root 环境，再执行passwd root时已经不再依赖 sudo 的二次授权，成功率更高。执行完再用su测一次。如果su仍然报错，检查一下 shadow 文件权限：
ls -l /etc/shadow正常应该是-rw-r----- 1 root shadow。权限不对会导致程序无法读取密码信息，也会报认证失败。
4.2 改完 /etc/passwd，普通用户却丢了 sudo
现象：有人为了让普通用户“变成 root”，把/etc/passwd里该用户的 UID 从 1000 改成 0，保存后该用户无法使用 sudo，桌面登录也进不去，系统所有需要 polkit 授权的操作全部失效。
原因：UID 是内核判断用户身份的最终依据，uid=0就是 root。把一个普通用户改成 UID 0，等于让 root 身份有了两个名字，sudo 缓存、桌面会话、日志记录全部错乱。同时该用户原来的家目录权限还是 1000，root 访问时又被目录属主挡住，两边对不上，行为非常诡异。
解决：重启进入 root shell，把/etc/passwd里该用户的 UID 改回 1000（或原来的值）。如果只是想让普通用户拿到 root 权限，正确动作是加 sudo 组：
sudo usermod -aG sudo 用户名改完确认：
groups 用户名输出里出现sudo即可。修改/etc/passwd这种高危操作，只适合改 shell、家目录路径这类非关键字段，不要碰 UID 和 GID。
4.3 sshd 改完不生效：多半是覆盖文件在捣乱
现象：把/etc/ssh/sshd_config里的PermitRootLogin改成 yes，/etc/init.d/ssh restart也执行了，但 root 依然连接不上，日志里显示Permission denied。
原因：Ubuntu 20.04 的 OpenSSH 服务加载配置时，先读取/etc/ssh/sshd_config，再读取/etc/ssh/sshd_config.d/*.conf，后加载的配置文件会覆盖前面的同名参数。系统升级或手动配置时如果有文件落在sshd_config.d里，主配置的修改就被覆盖。还有一个可能是 sshd 语法检查没跑，配置文件里存在错误导致服务实际没重启成功。
解决：用最终生效配置检查命令看真实值：
sudo sshd -T | grep -i permitrootlogin sudo sshd -T | grep -i passwordauthentication如果输出permitrootlogin no，说明确实被覆盖。列出目录文件：
ls -la /etc/ssh/sshd_config.d/有自定义配置文件的话，把内容改成需要的参数，或者删掉该文件后在主配置里修改。注意Match块也会限制 root 登录，sshd_config文件末尾常见这种写法：
Match User root PermitRootLogin no它会把全局PermitRootLogin yes覆盖为 no。sshd -T的输出里能看到最终值，排查时以它为准。
4.4 桌面登录 root 提示认证失败
现象：GDM 登录界面输入 root 和正确密码，画面闪一下又弹回登录界面，没有具体错误信息。
原因：root 密码没问题，卡在 PAM 的认证规则上。/etc/pam.d/gdm-password里pam_succeed_if.so user != root quiet_success这条规则在认证成功后追加了第二层判断，专门把 root 挡在图形会话外。键盘输入正确密码只过了第一关，第二关直接把认证结论改成失败。
解决：编辑/etc/pam.d/gdm-password，把user != root那一行注释掉，保存后重启 GDM：
sudo systemctl restart gdm3如果重启后问题还在，检查是否还有其他的 PAM 配置引入了类似规则，比如/etc/pam.d/gdm-autologin里的自动登录配置。grep -r "user != root" /etc/pam.d/可以搜索出所有相关位置，逐行排查。
5. 忘记 root 密码的应急恢复与后续建议
密码设完不等于以后再也不用管。系统跑上半年，密码忘了很常见，尤其是那些 root 只用于偶尔排查的机器。恢复方法取决于手里有什么权限。
有 sudo 权限时直接重设：
sudo passwd root没有 sudo 权限但能物理接触机器时，用恢复模式最稳。开机进 GRUB 菜单，选择“Advanced options for Ubuntu”进 recovery mode，再选“root Drop to root shell prompt”，挂载文件系统后改密码：
mount -o rw,remount / passwd root虚拟机里如果这一步进不去，还能在 GRUB 启动参数上动手：编辑启动项，在linux /boot/vmlinuz...那一行末尾追加init=/bin/bash，启动后直接就是 root shell。嵌入式板卡上（比如 RK3588 烧写的 Ubuntu 20.04）厂家镜像常默认就开 root，反而需要反过来把 root 密码设成强密码再关闭密码登录。
恢复完成后验证一次再关机，避免改了密码又忘记落盘。我的习惯是把 root 密码放进本地密码管理器，同时确保至少一个普通用户保留 sudo 权限，两个密码分开存。root 密码丢失时用普通用户兜底，普通用户出问题用 root 恢复，互为后备。
希望帮到你。
本文还有配套的精品资源，点击获取