企业官网建设流程全解析

1. 为什么 root 登录这件事值得单独拿出来说

很多人第一次接触 Linux 服务器，装完系统第一件事就是想办法用 root 直接登录。这个需求本身不复杂，但背后牵扯的东西比想象中多：默认配置为什么禁用 root 远程登录、改哪个文件、改完为什么不生效、改完之后安全上要注意什么。我见过太多人在这上面反复折腾，改完配置重启服务，结果还是连不上，最后发现是 SSH 配置里有两处互相打架。

这篇内容就是围绕“Ubuntu 设置 root 用户登录”这个具体操作展开，把整个链路讲透。适合刚接手 Ubuntu 服务器、需要临时或长期使用 root 权限的运维新手，也适合已经改过配置但没搞明白原理的人。核心关键词就一个：Ubuntu root 登录。我会从默认策略讲起，到具体改哪个文件、怎么改、怎么验证，再到改完之后的安全收尾，全部用可复现的步骤说清楚。

需要先明确一点：Ubuntu 默认不允许 root 用户通过密码直接登录 SSH，这是上游发行版的安全策略，不是 bug。你要做的不是“修复”它，而是“按需放开”。放开的方式有好几种，选哪种取决于你的使用场景。下面我会把每种方式的适用条件和操作细节都列出来，你对着自己的情况挑就行。

2. 先搞清楚 Ubuntu 默认为什么不让 root 登录

2.1 默认配置的两道锁

Ubuntu 在 SSH 层面做了两层限制。第一层是PermitRootLogin这个参数，在默认的 sshd 配置文件里通常被注释掉或者显式设为prohibit-password。这个值的意思是：允许 root 用户登录，但不接受密码认证，只接受密钥认证。第二层是 root 账户本身在默认安装时没有设置密码，或者密码被锁定，导致即使你想用密码登录也没有凭据可用。

这两层锁是配合使用的。prohibit-password保证了即使有人暴力破解 root 密码，也无法通过密码方式登录；root 账户无密码则保证了本地 su 切换也需要额外配置。所以当你想要“用 root 直接登录”时，实际上要同时处理这两个层面，只改一个往往不生效。

注意：不同 Ubuntu 版本默认值有差异。20.04 和 22.04 的默认 sshd_config 里PermitRootLogin通常是注释状态，但实际生效值是prohibit-password。24.04 延续了这个策略。所以你不能只看文件里写没写，要用sshd -T查实际生效值。

2.2 为什么有人非要 root 登录

从运维规范角度，直接使用 root 登录并不是推荐做法。但实际场景里，以下几种情况确实需要：一是临时接手一台老服务器，只有 root 密码，没有其他普通用户；二是在隔离的测试环境里，不想每次操作都加 sudo；三是一些自动化脚本或老旧工具硬编码了 root 连接方式，改造成本高于直接放开 root。

我的建议是：生产环境尽量用普通用户加 sudo，测试环境或短期调试可以临时放开 root，用完就关。下面讲的操作，你根据自己环境的风险等级决定要不要长期保留。

3. 改配置之前必须确认的三件事

3.1 确认你有其他可用的登录方式

这是最重要的一条。在你改 root 登录配置之前，确保当前至少有一个普通用户可以通过 SSH 正常登录，并且这个用户有 sudo 权限。原因很简单：万一你改配置改错了，sshd 启动失败，你还能用普通用户进去修。如果你只有 root 一个入口，改完连不上，那就只能去机房接显示器了。

验证方法很简单，新开一个终端窗口，用普通用户 ssh 登录一次，能进去就说明有后路。然后在这个普通用户下执行sudo -l，确认有(ALL:ALL) ALL或类似的全部权限。

3.2 确认 sshd 配置文件的加载顺序

Ubuntu 的 SSH 配置不是只有一个文件。主配置文件是/etc/ssh/sshd_config，但在sshd_config开头通常有一行Include /etc/ssh/sshd_config.d/*.conf。这意味着/etc/ssh/sshd_config.d/目录下的所有.conf文件也会被加载，而且加载顺序在主线配置之后，会覆盖主线里的同名参数。

我踩过的坑：在sshd_config里把PermitRootLogin改成了yes，重启服务后死活不生效。查了半天才发现sshd_config.d/目录下有个50-cloud-init.conf，里面写着PermitRootLogin prohibit-password，把主文件的设置覆盖了。所以改之前先执行ls /etc/ssh/sshd_config.d/，看看有没有额外配置文件。

3.3 确认 root 账户的密码状态

执行sudo passwd -S root查看 root 账户状态。输出第二列如果是L，表示密码被锁定；如果是P，表示已设置密码可用。默认情况下 Ubuntu 的 root 是L状态。你需要先用sudo passwd root给 root 设置一个密码，才能进行后续的密码登录测试。

设置密码时终端不会显示字符，这是正常的。密码强度建议至少 12 位，包含大小写字母、数字和符号。不要用123456或者password这种，root 账户一旦被爆破，整台机器就没了。

4. 具体操作：三种放开 root 登录的方式

4.1 方式一：允许 root 密码登录（最直接，风险最高）

这种方式就是让 root 可以用密码直接 SSH 登录。操作分三步。

第一步，给 root 设置密码：

sudo passwd root

按提示输入两次新密码。完成后用sudo passwd -S root确认状态变成P。

第二步，修改 SSH 配置。先检查sshd_config.d/目录：

ls /etc/ssh/sshd_config.d/

如果有文件里包含PermitRootLogin，直接改那个文件。如果没有，就改主配置文件：

sudo vi /etc/ssh/sshd_config

找到PermitRootLogin这一行，改成：

PermitRootLogin yes

如果这一行被注释掉了，去掉前面的#。如果找不到这一行，在文件末尾手动添加。

第三步，重启 SSH 服务：

sudo systemctl restart ssh

然后用sshd -T | grep permitrootlogin确认生效值是yes。

提示：重启 ssh 服务不会断开你当前的连接，但新连接会使用新配置。所以你可以放心在现有会话里操作，然后用另一个终端测试新连接。

4.2 方式二：只允许 root 密钥登录（推荐折中方案）

这种方式下 root 不能用密码登录，但可以用 SSH 密钥登录。安全性比密码高很多，适合需要 root 权限但又不想暴露密码入口的场景。

操作上，先把你的公钥放到 root 的authorized_keys里：

sudo mkdir -p /root/.ssh sudo chmod 700 /root/.ssh sudo vi /root/.ssh/authorized_keys

把公钥内容粘贴进去，保存。然后设置权限：

sudo chmod 600 /root/.ssh/authorized_keys sudo chown -R root:root /root/.ssh

SSH 配置里保持PermitRootLogin prohibit-password不变，或者显式写成：

PermitRootLogin prohibit-password

重启 ssh 服务后，用密钥测试 root 登录。这种方式下，即使有人知道 root 密码，也无法通过 SSH 密码登录，必须持有对应私钥。

4.3 方式三：用普通用户登录后 su 或 sudo 切换（最安全）

这种方式不放开 root 的 SSH 登录权限，而是用普通用户登录，然后通过sudo -i或su -切换到 root。这是生产环境的标准做法。

普通用户需要加入 sudo 组：

sudo usermod -aG sudo 用户名

然后该用户登录后执行sudo -i就能获得 root shell。这种方式的好处是：SSH 层面只暴露普通用户，攻击面小；所有操作有 sudo 日志可查；可以精细控制哪些用户能提权。

如果你只是偶尔需要 root 权限，强烈建议用这种方式，而不是直接放开 root 登录。

5. 改完之后怎么验证和排查

5.1 验证配置是否真正生效

不要只看配置文件里写了什么，要看 sshd 实际加载的值。执行：

sudo sshd -T | grep -i permitrootlogin

输出应该是permitrootlogin yes或permitrootlogin prohibit-password，取决于你选的方式。如果输出和你的预期不符，说明有别的配置文件覆盖了你的设置。

再确认 root 账户状态：

sudo passwd -S root

输出第二列是P才表示密码可用。

最后用另一个终端实际测试：

ssh root@服务器IP

能进去就说明配置成功。

5.2 常见问题速查表

5.3 我踩过的两个坑

第一个坑：改完sshd_config后执行sudo systemctl restart ssh，但服务启动失败，原因是配置文件里有个拼写错误。幸好当前会话没断，用sudo sshd -t查出了具体行号。所以改完配置先跑一遍语法检查，再重启服务。

第二个坑：在云服务器上改完配置，本地怎么都连不上，最后发现是云平台的安全组只放行了特定 IP，而我换了网络环境。这种情况和 SSH 配置无关，但很容易误判。排查时先用telnet 服务器IP 22确认端口通不通，再查 SSH 日志/var/log/auth.log。

6. 放开 root 登录后的安全收尾

6.1 至少要做这三件事

第一，改 SSH 端口。默认 22 端口是扫描重灾区，改成 1024 以上的非标准端口能过滤掉大量自动化扫描。改端口在sshd_config里改Port参数，同时记得更新防火墙规则。

第二，禁用密码认证，只用密钥。如果必须保留 root 登录，至少把PasswordAuthentication设为no，强制密钥登录。这样即使 root 密码泄露，没有私钥也进不来。

第三，限制登录来源 IP。在云平台安全组或本机 iptables/ufw 里，只允许你常用的 IP 段访问 SSH 端口。这样即使密码和密钥都泄露，攻击者从其他 IP 也连不上。

6.2 用完记得关

如果只是临时需要 root 登录，比如迁移数据或调试某个服务，用完就把PermitRootLogin改回prohibit-password或no，然后重启 ssh 服务。不要图省事一直开着。我自己的习惯是：改配置的时候在日历上设个提醒，第二天确认不需要了就关掉。

6.3 监控和日志不能少

放开 root 登录后，定期检查/var/log/auth.log，关注有没有异常的 root 登录尝试。可以配合fail2ban这类工具，对多次失败的登录尝试自动封 IP。虽然不能完全阻止攻击，但能大幅提高攻击成本。

另外，建议给 root 登录配置邮件告警或 webhook 通知。一旦有 root 登录成功，你立刻能收到消息。如果登录时间不是你操作的，可以第一时间响应。

7. 关于 sudo 和 root 登录的取舍

7.1 sudo 的优势在哪里

sudo 的核心价值是“最小权限原则”和“操作可追溯”。普通用户平时以低权限运行，需要提权时临时输入密码，所有操作记录在/var/log/auth.log里。这样即使某个普通用户的密码泄露，攻击者也需要额外步骤才能提权，而且会留下日志。

root 直接登录则没有这层缓冲。一旦 root 密码或密钥泄露，攻击者直接获得最高权限，而且很难区分是正常操作还是入侵行为。所以从安全架构角度，sudo 方案优于 root 直接登录。

7.2 什么情况下可以接受 root 登录

以下几种情况我认为可以接受 root 直接登录：一是完全隔离的内网测试环境，不暴露公网；二是短期调试，且已经配置了密钥登录和 IP 白名单；三是自动化工具确实不支持 sudo 提权，改造成本过高。除此之外，生产环境一律用 sudo。

如果你不确定自己的环境属于哪种，那就默认用 sudo。多一步提权操作，换来的是安全性和可追溯性，这笔账怎么算都划算。

7.3 一个折中配置示例

如果你确实需要 root 登录，但又想保留一定安全性，可以用这个配置组合：

PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes AllowUsers root@你的固定IP 普通用户名@你的固定IP

这个配置的意思是：root 只能用密钥登录，且只允许从指定 IP 登录；密码认证全局关闭；只允许指定用户从指定 IP 连接。这样即使密钥泄露，攻击者不在你的 IP 段也连不上。当然，IP 是动态的话需要额外方案，这里不展开。

8. 一些容易忽略的细节

8.1 云服务器和本地虚拟机的差异

云服务器通常有额外的安全组或网络 ACL，SSH 配置改对了但安全组没放行，照样连不上。本地虚拟机则要注意网络模式，NAT 模式下需要端口转发，桥接模式下虚拟机会获得独立 IP。排查问题时先把网络层确认清楚，再查 SSH 配置。

另外，部分云平台提供 VNC 或控制台登录方式，这是你改坏 SSH 配置后的救命通道。操作前确认一下你的云平台有没有这个功能，有的话记下入口位置。

8.2 root 的 shell 和环境变量

用su -和su的区别在于是否加载 root 的登录环境。su -会加载/root/.bashrc和/root/.profile，环境变量更完整。sudo -i类似su -，也是模拟登录 shell。如果你发现切换后某些命令找不到，大概率是环境变量没加载，用带-或-i的方式切换。

8.3 密钥权限问题

root 的.ssh目录权限必须是 700，authorized_keys必须是 600，且属主必须是 root。权限不对的话，SSH 会拒绝使用密钥，日志里会提示Authentication refused: bad ownership or modes。这个错误很隐蔽，因为从客户端看只是“认证失败”，没有具体原因。遇到密钥登录不上的情况，先检查权限。

8.4 配置文件的注释陷阱

sshd_config里很多参数默认是注释状态，但注释不代表不生效。sshd 有内置默认值，注释掉只是使用默认值，不是禁用。比如PermitRootLogin被注释时，实际生效值是prohibit-password，而不是“无限制”。所以改配置时不要以为注释掉就等于放开，要用sshd -T看实际值。

9. 最后分享几个实操习惯

我自己的习惯是：每次改 SSH 配置前，先备份原文件sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak。改完先跑sudo sshd -t检查语法，通过后再重启服务。重启后不关当前会话，新开终端测试，确认没问题再关旧会话。这套流程帮我避免了好几次把自己锁在外面的情况。

另外，如果你管理多台服务器，建议用配置管理工具统一管理 SSH 配置，而不是手动一台台改。手动改容易漏、容易不一致，时间长了就是隐患。小规模用 Ansible 的 lineinfile 模块就能搞定，大规模上更完整的配置管理方案。

root 登录这件事，技术难度不高，但细节多、影响大。改之前想清楚为什么要改、改完怎么验证、用完怎么收尾，比急着敲命令重要得多。