1. 为什么 Ubuntu 要默认挡掉 root 的远程登录先搞清楚这不是故障1.1 报错现场Permission denied (publickey,password)我第一次踩这个坑是在给一台 Ubuntu 22.04 的服务器初始化环境的时候。用 root 账号执行ssh root服务器IP系统直接甩回来一行root192.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 rootroot 账号在系统里基本处于锁定状态压根没有可用的密码。确认方法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改成yesroot 密码输得再正确服务端也会直接拒绝因为它压根不接受密码这种认证方式。处理方式有两个方向。一是把密码认证打开在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 root192.168.1.0/24 root122.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 更稳的替代方案普通用户加 sudoroot 远程登录未必是必须的最后说点经验之谈。在绝大多数场景下root 远程登录其实不是必需品。我自己维护服务器时日常使用的是普通用户账号加 sudo 提权偶尔才执行sudo su -切到 root 环境。这套模式有几个实打实的好处普通用户登录后所有 sudo 操作都会产生审计日志出问题能追溯具体执行过什么命令。即使普通用户密码泄露攻击者拿到的只是低权限账号破坏范围和 root 差了不止一个量级。团队协作时给每个运维人员分配独立账号比大家共用 root 密码好管理得多。所以我的结论是这样如果你是单机个人使用完全可以在做好安全措施的前提下开启 root 远程登录如果是团队协作或者服务器直接暴露在公网建议走“普通用户加 sudo 加密钥登录”的路线root 远程登录能不开就不开。如果某些测试环境实在绕不开 root 远程登录那至少把 IP 限制、密钥认证、fail2ban 这三件事一起做了。开启 root 远程登录本身只是几行配置的事真正考验人的是开启之后能不能让这台服务器在公网上睡得踏实。我自己在服务器上的最终配置一直都是PermitRootLogin prohibit-password配合密钥登录日常使用方便安全上也能安心。