侵入式双向链表
2026/9/30 11:25:44
1. 为什么 Ubuntu 要默认挡掉 root 的远程登录？先搞清楚这不是故障
1.1 报错现场：Permission denied (publickey,password)
我第一次踩这个坑，是在给一台 Ubuntu 22.04 的服务器初始化环境的时候。用 root 账号执行ssh root@服务器IP，系统直接甩回来一行：
root@192.168.1.101: Permission denied (publickey,password).当时我的第一反应是密码记错了，赶紧重新设置 root 密码再试一次，结果还是被拒。来回折腾了十几分钟，差点以为服务器被人改过 SSH 配置。最后冷静下来翻了翻/etc/ssh/sshd_config，才意识到问题根本不在密码，而在于系统默认就没打算让你用 root 走远程登录这条通道。
如果你也遇到过一模一样的报错，可以先把“是不是被人入侵了”这个顾虑放下。绝大多数情况下，这就是 Ubuntu 的默认安全策略在起作用。换句话说：不是你的密码错了，是系统默认不允许 root 远程登录。这篇文章要做的，就是把背后的机制讲透，再给你一条能落地的三步解决方案。
1.2 sshd 的默认策略：是哪个参数在拦你
SSH 服务端所有登录策略都集中在/etc/ssh/sshd_config这个文件里。控制 root 远程登录的是其中一个参数，叫PermitRootLogin。它有四个常见取值，区别非常关键：
| 取值 | 含义 | 适用场景 |
|---|---|---|
| yes | 允许 root 用密码或密钥登录 | 内网测试环境、个人服务器 |
| prohibit-password | 允许 root 登录，但只接受密钥，不接受密码 | 云服务器、需要 root 直连的生产环境 |
| forced-commands-only | 只允许 root 执行指定命令，不给 shell | 自动化运维、备份脚本专用 |
| no | 完全禁止 root 登录 | Ubuntu 的默认推荐方向 |
Ubuntu 从很早的版本开始，默认策略就是prohibit-password或no这个方向。它想表达的是：你可以通过sudo su -切换成 root 身份去做事，但别让 root 账号直接暴露在网络登录入口上。至于为什么这么设计，下面细说。
1.3 Ubuntu 的 sudo 哲学：为什么系统默认不让你 root 裸奔
很多人心里会有个疑问：服务器是我买的，root 密码也是我设的，凭什么不让我登录？这里其实藏着一个很重要的系统设计理念。root 在 Linux 里是拥有全部权限的超级管理员，正因为权限太大，一旦密码泄露，或者你在 root 身份下误执行了危险命令，后果通常不可逆。
所以 Ubuntu 在设计上更鼓励的做法是：普通用户负责日常操作，需要提权时用sudo临时切换。每一次高风险操作都会触发密码确认，也能在日志里留下记录，相当于给服务器上了一道保险。禁止 root 远程登录，就是这个理念在登录入口的延伸。
明白了这层逻辑之后，再看到“Ubuntu 禁止 root 远程登录”就不会觉得是 bug 了。它只是一个默认的安全开关。你知道开关在哪里，又确实有合理的业务需求，完全可以手动打开它。
2. 三步开启 root SSH 远程登录：密码、配置文件、重启验证
先说结论：在 Ubuntu 22.04/24.04 这类系统上，开启 root 远程登录只需要三步——设置 root 密码、修改sshd_config里的PermitRootLogin、重启 SSH 服务。每一步都不复杂，但顺序最好不要乱。
2.1 第一步：给 root 设置一个可用密码
如果你平时都是用普通账号加 sudo 办事，root 账号很可能根本没有密码，或者密码早就被忘了。这种情况下，就算放开了 SSH 策略，你依然登录不进去。
先执行这条命令，给 root 设置新密码：
sudo passwd root系统会提示输入新密码，连续输两次确认。这里有两个额外建议：第一，这个密码不要和普通用户密码相同；第二，尽量用高强度密码。原因很直接，后面如果开了PermitRootLogin yes，它就是远程登录的唯一密码凭据，也是网络上攻击者集中爆破的目标。
提示：如果你确定 root 密码没问题，这一步可以直接跳过。不确定就去重置一次，成本很低，别等到连不上了再着急。
2.2 第二步：修改 sshd_config 里的 PermitRootLogin
用编辑器打开 SSH 服务端配置文件：
sudo vim /etc/ssh/sshd_config找到这一行（通常在文件前半部分）：
#PermitRootLogin prohibit-password去掉开头注释符#，再根据实际需求修改。如果只是内网环境测试，想省事一点，可以改成：
PermitRootLogin yes如果你希望 root 只能通过密钥登录、拒绝密码登录，那就保留并取消注释这一行：
PermitRootLogin prohibit-password两者的区别在外面那节表格里已经说过了：yes是密码和密钥都放行；prohibit-password是只放行密钥。云服务器上如果你已经配过公钥，用后者明显更安全；个人内网测试机图方便，用yes也不是不行，但后续要做好安全加固。
改完不要急着重启，先养成一个好习惯：检查配置语法。
sudo sshd -t如果命令没有输出任何错误，说明配置语法没问题，可以进入下一步。
2.3 第三步：重启 sshd 服务并验证连接
Ubuntu 上 SSH 服务名通常叫ssh而不是sshd，这一点和 CentOS 不太一样，很多人会在这里栽跟头。执行：
sudo systemctl restart ssh然后确认服务状态：
systemctl status ssh看到active (running)基本就稳了。接下来验证一下，在本地终端执行：
ssh root@你的服务器IP输入 root 密码，如果顺利，你会看到提示符变成root@主机名:~#。到了这一步，说明整条链路已经完全打通。
2.4 为什么我改的是 sshd_config 而不是 ssh_config
实际答疑时，经常有人问“我明明改了配置，为什么还是不生效？”我一问才知道，他把/etc/ssh/ssh_config和/etc/ssh/sshd_config弄混了。这俩文件名只差一个字母，但角色完全不同。
ssh_config是 SSH 客户端的配置文件，决定“我这个客户端去连接别人时怎么表现”；sshd_config是 SSH 服务端的配置文件，决定“我的服务器如何让别人连接进来”。我们这次是修改服务器登录策略，所以要改的一定是后者。
另外还有一个隐蔽的坑：较新版本的sshd_config底部通常会引入一个碎片配置目录，类似：
Include /etc/ssh/sshd_config.d/*.conf如果碎片目录里的配置和主文件冲突，你会发现改了主配置却不生效。这个问题在云服务器上尤其常见，我在下一节给出完整的排查链路。
3. 开了配置还是连不上？四个高频原因与完整排查链路
三步写完很简单，但真实世界里，我见过太多人改完配置依然连接失败。如果你也卡在这里，别急着怀疑系统坏了，按下面的链路一步步排查，大概率能找到根因。
3.1 定位第一件事：用 ssh -v 看清失败方向
排查的第一步不是乱改配置，而是让客户端把连接过程完整打印出来：
ssh -v root@你的服务器IP输出里会出现一大段调试日志，重点关注最后几行的特征。三种典型报错，对应完全不同的排查方向：
| 报错特征 | 含义 | 优先排查方向 |
|---|---|---|
| Permission denied (publickey,password) | 网络通了，服务端拒绝登录凭据 | root 密码、PermitRootLogin、认证方式 |
| Connection timed out | 网络层不通 | 防火墙、安全组、路由 |
| Connection refused | 端口没监听 | sshd 服务状态、监听地址 |
先看清是哪一种，再动手。很多人上来就把PermitRootLogin改来改去，结果问题根本不在配置上，白白浪费时间。
3.2 高频原因一：PermitRootLogin 被碎片配置覆盖
这是我在云服务器上踩过最深的坑，没有之一。很多云服务商的 Ubuntu 镜像会在/etc/ssh/sshd_config.d/目录里放一个类似50-cloud-init.conf或60-cloudimg-settings.conf的文件，里面往往写着：
PermitRootLogin no问题在于，sshd 处理配置的顺序是：先读主配置，再读碎片目录。后面的配置如果和前面的冲突，会直接覆盖前面的值。你在主配置里辛辛苦苦改成yes，碎片文件又强制改成no，结果自然永远是 Permission denied。
排查方法很简单，把两边的配置都扫出来看看：
sudo grep -r "PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/如果发现冲突，要么修改碎片文件里的对应项，要么直接把碎片文件里那一行注释掉。改完再用sudo sshd -t检查语法，然后重启服务验证。
3.3 高频原因二：root 密码根本没设置成功
这个原因听起来有点基础，但实际遇到的人非常多。很多刚接触 Linux 的用户会默认“root 账号天生就有密码”，或者以为普通用户密码就是 root 密码。实际上，如果之前从来没有执行过sudo passwd root，root 账号在系统里基本处于锁定状态，压根没有可用的密码。
确认方法：
sudo passwd -S root如果输出显示密码状态是L，说明账号确实被锁定了，需要回到 2.1 的步骤重新设置密码。这里还要澄清一个容易混淆的点：用sudo su -能切换到 root，不代表远程登录也能成功。本地切换走的是 sudo 授权机制，远程登录走的是 SSH 的密码验证机制，两条通道不是一回事。
3.4 高频原因三：防火墙规则或 sshd 根本没重启
有一次帮朋友排障，配置都改对了，root 密码也重新设置过，但就是连不上。最后发现他改完配置之后压根没有重启服务，系统还在用老配置运行。修改sshd_config之后，一定记得执行：
sudo systemctl restart ssh另外一个容易被忽略的问题是监听地址。部分服务器有多张网卡，SSH 默认可能只监听某个内网地址，其他 IP 自然连不上。用这个命令看监听情况：
sudo ss -tlnp | grep ssh如果监听地址不是你预期的那一个，去配置里找ListenAddress参数修改。同时，如果启用了 UFW 防火墙，还要确认 22 端口已放行：
sudo ufw status sudo ufw allow 22/tcp这些基础项看起来不起眼，但往往是“改了一天配置还是不生效”的元凶。
3.5 高频原因四：公钥认证拦截了密码登录
还有一种比较隐蔽的情况：部分云服务器镜像默认只开放公钥认证，PasswordAuthentication被设成了no。这时候你就算把PermitRootLogin改成yes，root 密码输得再正确，服务端也会直接拒绝，因为它压根不接受密码这种认证方式。
处理方式有两个方向。一是把密码认证打开，在sshd_config里加：
PasswordAuthentication yes另一种更推荐的做法是走密钥登录：把本机公钥追加到服务器的/root/.ssh/authorized_keys文件里，然后让PermitRootLogin保持prohibit-password。这样 root 能远程登录，又避开了密码被暴力破解的风险。
这里有个权限细节非常容易踩坑。authorized_keys和它所在的/root/.ssh目录，权限过大时 sshd 会出于安全考虑直接拒绝该密钥。正确设置是：
chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys所以，如果配置看起来都对但依然失败，重点检查认证方式是不是被锁死成了公钥专用。
4. root 放行之后，这些安全加固动作请一起做
三步走完，root 远程登录的问题已经解决了。但如果你打算把服务器暴露在公网上，我强烈建议不要只做到这一步就收工。你能轻松打开这个功能，那些全天候扫描公网的攻击脚本同样也在盯着。
4.1 最小开放原则：限制来源 IP
如果你只是自己一台机器在用，完全可以把 root 登录的来源限制在信任 IP 范围内。在sshd_config里可以这样写：
PermitRootLogin yes AllowUsers root@192.168.1.0/24 root@122.10.x.x匹配到AllowUsers规则的来源 IP 才能用 root 登录，其他地址一律拒绝。这个做法的核心思想很朴素：与其和无数攻击者斗智斗勇，不如直接把入口缩小到你信得过的网络范围。
当然，如果家庭宽带是动态 IP，写死 IP 会给自己添麻烦。这时候可以退一步，用下面的密钥方案来补位。
4.2 密钥认证优先：建议直接关掉密码登录
公网服务器上，密码暴力破解是最常见的安全威胁之一。密码设置得再复杂，也架不住分布式字典猜测的持续轰炸。相比之下，SSH 密钥的强度要高几个量级，只要私钥不泄露，基本不存在被猜中的可能。
所以我的实际建议是这样的：就算开了 root 登录，也尽量把认证方式收敛为密钥。配置组合可以是：
PermitRootLogin prohibit-password PasswordAuthentication no PubkeyAuthentication yes第一次连接时先把公钥传上去，确认可以用密钥正常登录之后，再把PasswordAuthentication改成no，重启 SSH 服务。做完这一步，服务器基本就和密码爆破说再见了。
这里分享一个实用小技巧：生成密钥时，如果你不想每次登录都输入一遍私钥密码，可以设置空 passphrase；但如果追求更高的安全性，还是建议设置一个。安全性和易用性永远是个选择题，没有绝对正确答案，只有适合你场景的选项。
4.3 更稳的替代方案：普通用户加 sudo，root 远程登录未必是必须的
最后说点经验之谈。在绝大多数场景下，root 远程登录其实不是必需品。我自己维护服务器时，日常使用的是普通用户账号加 sudo 提权，偶尔才执行sudo su -切到 root 环境。
这套模式有几个实打实的好处：
- 普通用户登录后，所有 sudo 操作都会产生审计日志，出问题能追溯具体执行过什么命令。
- 即使普通用户密码泄露，攻击者拿到的只是低权限账号，破坏范围和 root 差了不止一个量级。
- 团队协作时，给每个运维人员分配独立账号，比大家共用 root 密码好管理得多。
所以我的结论是这样：如果你是单机个人使用，完全可以在做好安全措施的前提下开启 root 远程登录；如果是团队协作，或者服务器直接暴露在公网，建议走“普通用户加 sudo 加密钥登录”的路线，root 远程登录能不开就不开。
如果某些测试环境实在绕不开 root 远程登录，那至少把 IP 限制、密钥认证、fail2ban 这三件事一起做了。开启 root 远程登录本身只是几行配置的事，真正考验人的是开启之后，能不能让这台服务器在公网上睡得踏实。我自己在服务器上的最终配置，一直都是PermitRootLogin prohibit-password配合密钥登录，日常使用方便，安全上也能安心。