从 Ubuntu 默认不允许直接用 root 登录到出现su: 认证失败的报错再到最后成功切换 root 账户这个流程几乎每个 Ubuntu 用户都会走一遍。很多人第一次接触 Ubuntu 时都会按其他 Linux 发行版的习惯去执行su -结果看到认证失败就愣住了。这篇文章就围绕着这个经典问题展开完整讲清楚 root 账户为什么默认被锁定、如何正确解锁、日常使用中推荐用哪种方式以及遇到各种报错时的真实排查经验。1. 为什么 Ubuntu 默认不让用 root 登录1.1 Ubuntu 的 sudo 机制很多刚从 CentOS 或老版本 Debian 转过来的用户会对 Ubuntu 的这套用户权限设计感到不适应。在 CentOS 的默认配置里root 账户是直接启用的安装系统时设置的就是 root 密码用ssh root服务器IP就能直接远程登录。但在 Ubuntu 里安装系统时创建的那个用户是一个普通用户这个普通用户具有 sudo 权限可以执行管理员命令。Ubuntu 默认不设置 root 密码等于把 root 账户的密码锁给焊死了。你在安装 Ubuntu 时整个过程根本不会让你设置 root 密码只让你创建一个带 sudo 权限的普通用户。这意味着 root 账户没有可用的密码自然也就无法通过su -切换更无法直接登录系统。这种设计思路是让所有操作都通过 sudo 来执行每一次敏感操作都会留下日志同时也避免用户长期以 root 身份操作导致误删系统文件。这个思路听起来很合理但对于习惯了 root 身份操作的运维人员来说确实需要适应。我自己刚接触 Ubuntu 时也觉得麻烦后来用久了才理解这样设计的初衷Ubuntu 面向的是桌面用户和开发者很多刚开始接触 Linux 的人如果直接用 root 操作很容易因为误操作把系统玩坏。相比之下sudo 机制相当于给危險操作加了一道提醒和记录。1.2 认识 “su: 认证失败”su: 认证失败这个报错出现在你输入su -然后输入 root 密码的时候。很多人第一次遇到时会反复确认自己有没有输错密码或者怀疑键盘布局出了问题。实际上根本原因是 root 账户根本没有密码你输入的任何一个密码都不可能通过认证。这里需要区分两个命令。su和sudo虽然都是用来提升权限的但机制完全不同。su -是切换用户默认切换到 root需要输入 root 账户的密码。sudo是当前用户以 root 身份执行命令需要输入的是当前用户的密码而不是 root 的密码。在 Ubuntu 默认配置里安装时创建的那个用户已经具有 sudo 权限所以使用sudo命令时输入自己的密码就能提权。理解了这两者的区别就明白了问题的根源想用su -切换 root前提是 root 账户必须先有密码。而 Ubuntu 默认不设置 root 密码所以你无论怎么输入都是认证失败。这不是你操作不对而是系统在保护自己。2. 启用 root 账户的完整操作流程2.1 启用前的准备工作在开始操作之前有几个前提条件需要确认。首先你当前登录的用户必须具有 sudo 权限。如果你安装系统时创建的第一个用户那这个用户默认就在 sudo 用户组里可以直接使用 sudo 命令。如果你是用其他方式获得的当前用户不确定它有没有 sudo 权限可以先执行sudo whoami如果输出的结果是root说明这个用户有 sudo 权限。其次建议在开始之前先备份一下重要数据。虽然sudo passwd root这个操作本身不会影响到现有数据但任何涉及账户和权限的修改都存在一定风险尤其是后面可能会用 root 身份去做系统级配置。我在实际操作中见过有人在启用 root 账户后顺手把系统里其他普通账户的权限改了导致系统出问题的情况。所以操作之前做好心理准备明确你启用 root 账户的目的到底是什么。还有一个容易被忽略的细节如果你是在远程服务器上操作启用 root 账户后还要考虑是否允许 root 通过 SSH 登录。如果不修改 SSH 配置即使 root 账户有密码了也无法远程登录只能在本地终端使用。这个后面我会专门讲。2.2 核心操作sudo passwd root启用 root 账户的操作其实只有一个命令。在终端中输入sudo passwd root系统会先提示你输入当前用户的密码注意这里输入的是当前用户的密码而不是 root 的密码。输入正确后会出现提示让你设置新的 root 密码并且需要输入两次确认。整个操作过程比较短但是这一个步骤就完成了 root 账户的解锁。这里需要注意输密码时的反馈。终端中不会显示你输入的密码也不会出现星号或者占位符你输入的内容是看不见的。很多人第一次用终端时以为自己输入没生效其实只是系统默认隐藏了输入。你只需要正常输入然后按回车即可。设置完成后root 账户就已经启用了。你可以使用su -切换也可以直接用 root 账户登录系统。但这里有个需要提醒的点密码要设置得足够复杂因为 root 账户一旦被启用就成了系统安全的重要防线。如果你设置的密码过于简单比如只有数字或者生日组合那在暴露到公网的服务器上被暴力破解的风险会非常高。2.3 验证 root 账户是否启用成功设置完密码之后需要验证一下切换是否真的生效。执行su -输入你刚才设置的 root 密码如果成功切换命令提示符会从$变成#并且当前目录会切换到 /root。你自己创建的那个普通用户的家目录通常是 /home/用户名而 root 用户的家目录是 /root这也是判断是否切换成功的一个直观标准。也可以使用命令行工具验证当前身份。执行whoami输出的结果应该是root。执行id -u输出的结果应该是0。如果这两个命令的输出符合预期说明 root 账户已经完全启用并且正常工作。验证完成之后你真的需要立即以 root 身份开始操作吗我的建议是验证完先用exit退出 root 身份回到普通用户去继续工作。这样做的原因是在不必要时保持普通用户身份可以有效避免误操作。特别是执行rm -rf、修改系统关键目录权限这类高风险命令时普通用户身份会多一层保护至少遇到权限不足时会让你停下来想一下。2.4 安全基准启用 root 后必须要做的加固启用 root 账户之后如果这台机器是公网服务器或者你会通过远程方式登录有几项安全配置是绝对不能跳过的。第一把 root 密码设置得足够复杂。长度建议不低于 16 位包含大小写字母、数字和特殊符号。这里分享一个我经常用的方法用一个完整的句子作为密码比如一句你熟悉的诗句再加上特殊符号这样既好记又不容易被暴力破解。第二修改 SSH 配置文件限制 root 的远程登录方式。root 使用密码通过 SSH 登录是风险最大的行为因为暴力破解工具可以反复尝试密码。更稳妥的做法是禁用 root 的密码登录只允许使用公钥认证。这个配置在/etc/ssh/sshd_config中具体如何操作我会在后面的章节详细展开。第三启用系统的日志审计功能。Ubuntu 默认的 auth.log 会记录所有与认证相关的日志包括 su 切换的记录。你可以通过检查/var/log/auth.log来监控是否有异常的 root 登录行为。如果发现日志中出现大量失败尝试记录说明有人正在尝试破解你的系统需要立即加强安全措施。3. 除了直接启用 root还有什么替代方案3.1 为什么我不推荐长期使用 root如果你看过我的其他文章会发现我多次强调过除非有明确的必要否则不要长期以 root 身份操作。这不是教条而是因为我确实在运维中遇到过太多因为 root 误操作导致的事故。举一个真实的场景。某次我在测试环境里用一个普通用户操作执行了一个删除日志的命令因为通配符没写对直接把一个程序目录下的文件删除了。好在只是测试环境没什么损失。但是同样的场景如果是在 root 身份下操作删除的可能就是系统目录。普通用户有权限限制系统关键文件会提示权限不足root 则没有限制任何误操作都会直接生效没有后悔的机会。另一个需要考虑的因素是很多软件在安装和运行时并不希望使用 root 身份。比如用 npm 安装某些全局包用 pip 安装 Python 包如果以 root 身份执行可能会污染系统目录甚至引发权限混乱。用普通用户安装在自己的家目录里反而更安全、更灵活。3.2 用 sudo 完成大部分管理操作实际上日常运维中需要使用 root 权限的操作用sudo都可以完成。Ubuntu 的默认设计就是让你用 sudo而不是直接切换 root。举几个实际场景。更新软件包时使用sudo apt update sudo apt upgrade这样只需要输入当前用户的密码。修改系统配置时使用sudo vim /etc/fstab以 root 身份打开编辑器。创建新用户时使用sudo useradd。如果你需要连续执行多条需要 root 权限的命令又不想每次都输入密码可以先用sudo -i进入一个 root 交互 shell操作完成后再用exit退出。如果你需要在脚本中执行需要 root 权限的命令也可以在脚本中设置免交互的 sudo 配置但这不是我现在推荐的做法。你在使用中发现输入密码太频繁了再去研究 sudoers 文件的精细配置也不迟。3.3 何时才真正需要启用 root既然有 sudo 可以处理绝大多数操作那什么时候才应该启用 root 账户呢根据我的经验主要有这几种情况。当你需要以 root 身份运行某个服务或脚本并且这个服务可能需要长期运行、自动重启时比如某些 Docker 部署方案、部分自建的监控脚本使用 root 身份可以省去很多权限适配的麻烦。当你需要调试一些涉及系统内核、设备驱动的程序时比如修改/sys下的设备参数、加载内核模块这些操作通常需要完整的 root 权限sudo 反而会因为环境变量的差异导致问题。当你需要执行一些会对系统做全局修改的脚本时比如批量修改某些系统配置文件直接使用 root 可以让脚本不需要处理各文件的权限问题。当然这些场景更推荐的做法是在用完 root 身份后立即退出不要让 root 会话一直挂着。4. 实操中的关键细节从密码设置到账户验证4.1 密码策略什么样的 root 密码才算合格在设置 root 密码时常见的安全标准是长度不低于 12 位但考虑到你设置的密码可能要面对公网暴力破解建议直接使用 16 位以上。字符组合要包含大小写、数字、特殊符号不要使用生日、姓名拼音、连续数字这类容易猜到的组合。如果你的密码与其他账户的密码相同或者与常用密码类似即使位数足够长也仍然存在风险。另一个实用的建议是不要使用第三方脚本或生成器产生的随机密码因为这类密码虽然安全性不错但你很难记住最后往往会把它存在某个笔记软件里反而增加了泄露风险。更好的做法是使用一个记忆锚点比如一句你熟悉的谚语把其中的首字母提取出来再插入数字和符号这样既容易记住又不容易被猜中。4.2 用 passwd 命令修改密码时的注意事项passwd命令虽然简单但在实际使用中有几个细节需要注意。如果你执行的是sudo passwd root那设置的是 root 密码。如果你执行的是passwd root在没有 root 权限的情况下普通用户是不能修改 root 密码的系统会提示权限不足。而如果你直接执行passwd不带任何参数修改的是当前登录账户的密码。有一个很多人会踩的坑在执行完sudo passwd root后忘记了当前用户密码然后退出登录准备用 root 登录测试发现 root 能登录但当前用户密码忘了。这种情况虽然不影响 root 使用但如果这是一个共享机器可能会带来不必要的麻烦。所以我建议在修改 root 密码之前先确认自己的普通用户密码是熟知的。4.3 验证过程切换后如何确认自己拥有完整权限完成切换后检查权限是否完整有一个简单有效的流程。执行id命令会输出当前用户的信息。root 用户的 UID 和 GID 都是 0对应的分组信息包含 root、adm、systemd-journal 等。如果你看到 UID 不是 0说明切换没有成功还在普通用户身份下。执行cat /etc/sudoers或者sudo -lroot 用户的 sudoers 配置能看到所有权限包括执行任意命令的权限。普通用户则会看到受限的 sudo 权限列表。还有一个更实用的测试以 root 身份运行一个需要高权限的命令比如iptables -L -n查看防火墙规则或者fdisk -l查看磁盘分区信息。这些命令在普通用户下会被拒绝或输出不完整在 root 身份下则能正常看到所有输出。5. 常见问题与排查技巧实录5.1 问题一密码正确却仍然提示 “认证失败”这种情况在职场上非常常见。明明刚刚设置了 root 密码执行su -时输入的密码也是刚刚设置的系统却依然提示认证失败。排查方向有两个。第一检查键盘布局。有些服务器为了安全会把键盘布局设置为美式英语但你在本地终端用的是中文输入法或本地键盘布局。这会导致输入的符号和数字与预期不符尤其是密码中包含、#、$之类的特殊符号时最容易出现问题。第二检查密码中是否包含空格。如果设置密码时手滑在结尾或中间加了空格输入时没有人能看出来但系统会把这个空格当成合法字符。这种情况下输入时多一个或少一个空格都会导致认证失败。可以重新执行一次sudo passwd root这次输入密码时格外注意不要带入空格。5.2 问题二sudo 命令也不能用了如果当前的普通用户本身不在 sudo 用户组里sudo命令会提示该用户不在 sudoers 文件中此时无法通过sudo passwd root设置 root 密码。这种情况通常出现在你使用了某个自定义用户或者从其他人手上交接了一台服务器。解决办法是切换到 root 身份。如果你还记得机器上有其他具有 sudo 权限的用户切换到那个用户再执行sudo passwd root。如果没有就需要进入恢复模式recovery mode来重置密码。Ubuntu 在开机时按住 Shift 键会进入 GRUB 菜单选择恢复模式后在恢复菜单中选择 root Drop to root shell prompt就能直接获得一个 root shell。在这个 shell 里执行passwd root就能重设 root 密码。恢复模式是绕过密码认证进入系统的方法但也意味着任何拿到你机器物理权限的人都能这么做。所以物理安全性同样重要不要把服务器的机箱随便让人碰到。5.3 问题三重启后 root 密码失效有些人设置完 root 密码后发现重启系统后密码又失效了这是非常罕见的情况。排查思路主要是检查系统中是否有定时任务或者第三方脚本在修改密码。某些安全加固脚本或入侵检测工具会自动轮换 root 密码如果安装过这类工具需要检查对应的配置。另一个可能性是 PAM (Pluggable Authentication Modules) 配置错误导致认证模块没有正确读取 root 密码。这种情况通常发生在修改过/etc/pam.d/目录下文件之后。如果恢复默认配置后问题依旧可能需要检查系统的是否正常。5.4 常见问题速查表现象可能原因解决思路su -提示认证失败root 密码未设置或输入错误使用sudo passwd root重设密码sudo提示用户不在 sudoers 文件用户不在 sudo 组使用恢复模式修改用户组配置无法连接 SSH 服务器root 被禁止远程登录修改 sshd_config 并添加公钥密码正确但登录被拒绝PAM 配置异常检查 /etc/pam.d/common-auth 等文件SSH 提示密码错误键盘布局或输入法问题使用英文键盘布局登录6. 远程连接 root 账户的额外配置6.1 SSH 配置允许 root 登录的正确方式如果你启用 root 账户是为了管理远程服务器那还需要进一步配置 SSH 服务。默认情况下Ubuntu 的 sshd 配置会禁止 root 用户通过 SSH 登录这是出于安全考虑。先检查当前配置。SSH 服务器的配置文件在/etc/ssh/sshd_config搜索PermitRootLogin这一行。默认情况下它的值是prohibit-password意味着 root 不允许使用密码登录但允许公钥认证。如果你执行grep PermitRootLogin /etc/ssh/sshd_config看不到任何输出说明配置文件中没有主动设置这一项系统使用默认值Ubuntu 的默认值就是禁止 root 密码登录。如果你希望 root 账户能够通过 SSH 登录有两种选择允许密码登录或者只允许公钥登录。我的建议是绝对不要使用PermitRootLogin yes配合密码登录。公网环境下的暴力破解攻击非常频繁密码登录等于放在大门上的稻草锁。而PermitRootLogin prohibit-password配合公钥认证则是目前安全性和便利性平衡最好的方案。具体配置方法编辑/etc/ssh/sshd_config确保包含以下配置PermitRootLogin prohibit-password PubkeyAuthentication yes修改完成后执行sudo systemctl restart sshd让配置生效。同时需要确认系统的防火墙放行了 SSH 端口默认是 22 端口。6.2 公钥认证让 root 登录更安全使用公钥认证登录 root 账户需要先在本地生成一对密钥。执行ssh-keygen -t ed25519 -C your comment生成密钥对公钥文件通常位于~/.ssh/id_ed25519.pub。然后将公钥内容追加到服务器上 root 用户家目录下的~/.ssh/authorized_keys文件中。在向服务器添加公钥时建议使用ssh-copy-id工具。如果你的本地客户端支持这个命令执行ssh-copy-id root服务器IP然后输入 root 密码公钥就会被自动添加到服务器端。之后测试登录确认公钥认证生效后就可以考虑在 sshd 配置中禁用 root 密码登录了。还有一个细节需要提醒在服务器端修改 sshd_config 时强烈建议先不要关闭你当前的连接。如果你使用的是命令行编辑器修改配置改完后先开一个额外的终端窗口测试新配置是否正常确认可以登录后再关闭旧连接。我现在就是这么操作的否则一旦配置写错又恰好没有其他登录方式就只能去云服务商的控制台通过 VNC 登录修复了。6.3 SSH 相关的坑与排查SSH 登录问题排查时有一个基本的排查顺序先确认网络连通性用ping或ssh -v输出调试信息确认 TCP 端口是否能通。然后检查密钥权限服务器端 authorized_keys 文件权限通常是 600家目录权限是 700如果权限过宽sshd 会拒绝使用这个公钥文件。很多次帮助朋友排查 SSH 问题发现都是权限问题。某个 sshd 配置项是StrictModes yes意味着 sshd 会检查密钥文件的权限如果发现其他用户也能读取或修改就会拒绝认证。解决办法是执行chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh。另一个常见问题是在/etc/ssh/sshd_config中启用了AllowUsers或AllowGroups限制但没有把 root 用户加入允许列表登录请求直接就被拒绝了。排查时不要只盯住PermitRootLogin也要检查是否有其他的限制项。7. 如果你的场景是云服务器还需要做什么7.1 云平台安全组放行规则云服务器与本地物理机不同除了系统内部的防火墙配置还有一个云平台层面的安全组策略。如果你在 Ubuntu 云服务器上开放了一个新的 SSH 登录方式比如修改了 SSH 端口或者把 root 的登录方式改成公钥认证都需要检查安全组是否放行了对应规则。安全组规则的修改位置在各云厂商的控制台一般称之为安全组或防火墙。如果你决定修改 SSH 默认端口比如从 22 改成 2222需要在安全组中放行 TCP 2222 端口。否则连接请求到不了系统系统层面的所有配置都是白费。7.2 云服务器的 root 登录实战建议对于云服务器我对 root 登录的建议会更加保守。如果一台服务器只部署了一些基本服务平时你只需要执行少数几条管理命令那完全不需要启用 root 账户直接用sudo就够了。如果服务器上有多个开发者需要协作更不应该共享 root 密码而是应该给每个人单独的 sudo 用户。如果确实需要 root 远程登录务必遵守几个原则只使用公钥认证不要使用密码登录把 SSH 端口改成非常规端口降低扫描攻击的概率配置 fail2ban 这类防护工具对频繁失败登录的 IP 进行暂时封禁。这些措施叠加起来能显著降低暴力破解和扫描攻击的风险。我在维护某生产环境时也曾为了便利给 root 开启了密码登录结果不到 24 小时日志里就出现了几百次来自不同 IP 的失败登录尝试。还好密码足够复杂没有被攻破但这件事让我彻底改掉了这个习惯。8. 最后的实操心得Ubuntu 的 root 账户启用只是权限管理的一小步背后涉及的是 Linux 的权限模型、sudo 机制、SSH 认证体系以及安全意识。这篇文章从su: 认证失败这个最常见的报错切入把从解锁 root、验证权限、配置 SSH、到加固安全的完整流程讲了一遍。我个人在实际操作中的体会是不要为了省事而放弃安全边界。Ubuntu 把 root 锁起来不是不让你用而是提醒你不要随意用。在绝大多数场景下sudo已经足够解决问题而当你真正需要 root 权限时认真思考为什么要用、用完怎么退出、对系统有哪些影响才是更重要的。最后再分享一个建议操作前养成查看当前身份的习惯。遇到权限问题时先执行whoami确认一下自己在哪个账户下切换了账户后执行完操作及时退出。这个简单的习惯能帮你避免很多权限相关的灾难。