1. 为什么非要折腾 root 远程登录先聊清楚利弊我猜你搜到这个标题大概率是刚装完 Ubuntu 24.04.3 LTS结果发现用 root 账号根本连不上 SSH或者压根没给 root 设置过密码登录时提示认证失败。我第一次踩这个坑是很多年前在服务器上部署项目习惯性地用 root 去连结果被拒之门外当时还以为是防火墙的问题折腾了好一阵才发现是 Ubuntu 默认就不让你这么干。先说清楚Ubuntu 从很早的版本开始就默认禁用 root 远程登录这和安全策略有关。它的设计思路是引导你使用 sudo 机制也就是日常操作用普通用户加上临时提权来完成而不是直接拿最高权限账户干活。这个思路本身没问题但在实际运维场景里尤其是管理云服务器、虚拟机或者树莓派之类的设备时root 直连常常会更方便——脚本部署、自动化运维、文件权限调整每一步都用 sudo 会显得很啰嗦而且某些服务以 root 身份启动会少很多奇怪的权限报错。所以这篇文章的目标很明确在 Ubuntu 24.04.3 LTS 上把 root 账户的密码设好然后修改 SSH 服务配置让 root 可以用密码或密钥远程登录。整个过程不算复杂但涉及几个关键配置项每一步都有它的道理我们边做边讲为什么。在动手之前我需要先给你打个预防针直接开放 root 远程登录确实存在安全风险。公网上的服务器每天都有人在扫描 SSH 端口如果你的 root 密码强度不够暴力破解只是时间问题。所以这篇文章里我会额外加一些常见的加固手段比如修改默认端口、限制来源 IP、使用密钥认证等。如果你只是在自己家里的内网虚拟机里折腾那按基础配置做就行如果服务器要上公网我建议你把安全章节认真看完。适合看这篇文章的人主要是这几类刚装好 Ubuntu 想在局域网里远程管理的初学者、需要在多台 Ubuntu 服务器上批量做运维的工程师、还有在 VMware 或 VirtualBox 里装虚拟机想用 SSH 访问的折腾党。整个过程我会给出完整命令和操作说明你跟着做就行同时也尽量解释配置项的含义让你不只会照着敲还能明白它在干什么。2. 环境准备这些前置条件不满足后面全是坑2.1 确认你的系统版本和网络状态在开始修改任何配置之前先把基础情况摸清楚。这里说的“摸清楚”包含三件事系统版本确认、网络连通性确认、SSH 服务端是否已安装。首先确认系统版本这个命令在任何 Debian 系系统里都通用lsb_release -a正常会输出类似这样的信息No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.3 LTS Release: 24.04 Codename: noble如果是这个版本你直接往下走如果你用是 22.04、20.04 甚至更老的版本配置思路几乎一样只是某些服务名可能略有差异。另外如果你的系统是刚装好的最小化安装可能连 net-tools 都没有这也不影响我们用 ip 命令就行。接着确认网络状态。SSH 是网络服务机器之间必须能互通才能连上。在 Ubuntu 上执行ip addr show查看你的网卡是否有 inet 地址。如果是 DHCP 自动获取一般会有一个 192.168.x.x 或 10.x.x.x 之类的地址。记下这个 IP它就是之后远程连接的目标地址。如果你发现网卡没有 IP那问题不在 SSH 配置而是网络本身没弄好先解决 DHCP 或静态 IP 的问题再回来。还有一点容易被忽略如果你是在虚拟机的 NAT 模式下操作宿主机和虚拟机之间往往还需要配置端口转发才能互通。所以我一般建议前期直接用桥接模式或者确保你能用普通用户 SSH 连上虚拟机再开始下面的操作。2.2 系统更新和 openssh-server 安装Ubuntu 24.04 默认通常不带 openssh-server只有 openssh-client。怎么区分你在终端里敲 ssh 命令能用来连接别人但别人连不上你——因为服务端压根没装。所以首要任务是装上服务端sudo apt update sudo apt install -y openssh-server在安装之前执行一次 apt update是为了拉取最新的软件源索引避免安装到旧版本或者出现依赖解析失败的情况。如果你的服务器在墙内原版源可能会比较慢可以换成国内镜像源具体操作网上很多这里不展开。安装完成后确认服务正常启动sudo systemctl status ssh看到 active (running) 就说明服务已经在跑。如果你的系统是 WSL 或者容器环境systemd 可能没有正常工作这种情况下 SSH 服务可能需要你手动启动但这个场景不在本文讨论范围内。还要确认一下 SSH 服务是否设成了开机自启sudo systemctl enable ssh这个命令会把这个服务链接到 systemd 的多用户目标里保证每次重启系统后 SSH 都能自动起来。如果你忘了这一步系统一重启远程就断开了人不在现场会相当被动。注意操作之前建议先确保至少有一个能用的终端会话不一定是 SSH本机终端也行。因为后面改 SSH 配置时一旦语法错误并重启服务你可能会把自己锁在外面。后面我会专门讲如何防止这种情况。3. 核心设置密码、SSHD 配置与重启生效3.1 给 root 设置一个强密码Ubuntu 默认的 root 账户密码其实是锁定的即使你安装系统时设置了用户密码root 依然没有可用密码。你可以直接 sudo passwd root 来检验如果提示 passwd: password expiry information changed 这类信息说明设置成功如果没设置过会要求你输入新密码。这里顺手提一句为什么 Ubuntu 默认要锁定 root因为很多新手会用 root 身份执行各种命令万一操作失误代价很高用 sudo 方式还能留下操作日志出了问题可以追溯。这个设计理念没错但如果你确实需要 root 远程登录那我们就得把锁解开。执行以下命令给 root 设置密码sudo passwd root系统会提示你输入新的密码并确认一次。这里我给个硬性建议如果你这台机器要上公网密码至少 16 位包含大小写字母、数字和特殊符号不要用生日、手机号、常见单词组合。暴力破解工具对纯数字和纯字母密码的破解速度超出你的想象。有朋友会问能不能不设密码直接用密钥登录在 SSH 配置里确实可以设置 PermitRootLogin prohibit-password这样 root 只能用密钥登录。这个选项更安全但前提是你得先把公钥部署到位。我们这篇文章会先讲密码登录因为步骤更直观密钥登录作为推荐方案在后面专门说。3.2 修改 SSHD 配置的每一个关键点改配置前强烈建议先备份原文件。备份的好处是万一你哪一步改错了或者新配置和系统里某个机制冲突可以秒回滚sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %Y%m%d)带日期后缀的备份更清晰以后看到也知道是什么时候做的备份。然后编辑配置文件sudo nano /etc/ssh/sshd_config接下来是整篇文章的核心你需要关注下面这几个配置项第一个是 PermitRootLogin。这个选项控制 root 是否允许通过 SSH 登录它有多个取值prohibit-password允许 root 登录但只能使用密钥认证不能用密码yes允许 root 用密码和密钥登录no禁止 root 登录在 Ubuntu 24.04 的默认配置里这一行通常是被注释掉的默认值其实是 prohibit-password。这就是为什么如果你之前已经给 root 设了密码依然没法用密码登录的原因。我们要改成 yesPermitRootLogin yes第二个是 PubkeyAuthentication。这个选项决定是否允许密钥登录默认是 yes一般不用动但你得确认为没有被设置成 no。如果你想关掉密码登录只留密钥那这个选项必须保持开启。第三个是 PasswordAuthentication。这个选项控制是否允许使用密码登录默认也是 yes。如果你打算长期用密码登录保持默认如果后续想加强安全性把它改成 no 并改用密钥那是后话。注意在 Debian 系系统上还有一个独立的配置文件 /etc/ssh/sshd_config.d/ 目录里面的配置会覆盖主配置文件的对应项。所以改完主配置文件之后记得检查这个目录下有没有其他配置覆盖了你的设置。常见的情况是 cloud-init 会在这里生成一个 60-cloudimg-settings.conf 之类的文件把 PasswordAuthentication 设成 no导致你改了主配置文件却不生效。检查的命令grep -r PasswordAuthentication /etc/ssh/sshd_config.d/如果输出的结果里有 no并且和你的预期冲突就要么改这个子配置文件要么把它的相关行注释掉。这个细节非常容易被忽略网上很多教程没说但你实际一测就知道问题了。还有一个经常被忽略的配置是 UsePAM它默认是 yes。在某些环境下如果 PAM 模块配置有问题root 登录也会被拒绝。如果前面都改对了还是连不上可以看一眼 /etc/pam.d/sshd 里的配置。不过大多数情况下默认配置不需要额外调整。3.3 重启服务让配置生效配置改完之后必须重启 SSH 服务才能生效sudo systemctl restart ssh这里有个安全细节在重启之前最好先验证一下配置文件语法是否正确。尤其当你改了比较多选项或者手一抖打错字符时语法错误会导致服务直接起不来sudo sshd -t这个命令会执行一次配置文件的语法检查。如果没有输出任何错误信息说明配置没问题可以放心重启。如果出现类似 /etc/ssh/sshd_config line XX: Bad configuration option 之类的错误就说明有地方写错了回去改完再检查一次。重启之后再确认一下服务状态sudo systemctl status ssh看到 active (running) 就说明 SSH 服务正常工作。然后在本机测试一下端口是否在监听sudo ss -tlnp | grep 22如果看到 0.0.0.0:22 或 [::]:22 的监听记录说明 SSH 服务已经在正常监听了。到这一步远程机器就可以尝试连接了。4. 实战验证从本机和远程分别测试连接4.1 本机回环测试本地验证的目的是确认改完配置之后不会把自己锁在门外。用回环地址自己连自己ssh rootlocalhost或者指定端口ssh -p 22 root127.0.0.1如果一切正常它会提示你输入密码输入之前设置的 root 密码成功后就进入了 root 的 shell。这一步成功了说明服务端配置没问题问题如果出在远程连接上那就是网络或客户端那边的事。我建议这一步一定要做。很多人在服务器上改完配置直接关掉当前终端然后从电脑上连发现连不上再想回服务器改配置就很麻烦。回环测试能帮你把服务端的问题在本地就排查掉。4.2 从另一台机器远程连接在另外一台电脑上用任意 SSH 客户端连接。Linux 或 macOS 直接用终端ssh root192.168.1.100Windows 的话可以用 Windows Terminal 里的 OpenSSH 客户端也可以直接用 PowerShell 敲同样的命令或者用 MobaXterm、Xshell、FinalShell 这类图形化工具。本质上都是 SSH 协议配置对了哪个工具都能连。如果你连接超时先检查网络通不通在客户端机器上 ping 服务器的 IP通的话再看端口通不通telnet 192.168.1.100 22如果端口不通大概率是防火墙拦截了。Ubuntu 24.04 默认用的是 ufw很多人装完系统顺手开了防火墙但忘了放行 22 端口。查看和放行的命令sudo ufw status sudo ufw allow 22/tcp sudo ufw enable注意 ufw enable 命令执行后系统防火墙会立即生效如果你当前是通过 SSH 连接操作的而还没有放行 22 端口这一步会直接断掉你的连接。所以最稳的操作顺序是先 allow 22/tcp 再 enable。4.3 连接失败的常见表现和快速判断我整理了一张速查表按症状定位原因排查效率会高很多现象可能原因排查方向Connection refusedSSH 服务没启动查 systemctl status sshConnection timed out防火墙拦截或网络不通查防火墙、ping、端口连通性Permission denied密码错误、PermitRootLogin 配置不对、PAM 限制检查密码检查 sshd 配置和子配置No supported authentication methods服务端不接受当前认证方式检查 PasswordAuthentication、PubkeyAuthenticationServer unexpectedly closed connection配置语法错误或服务启动崩溃sshd -t 检查语法查看 /var/log/auth.log这些都是我实际踩过的坑。尤其是 Permission denied 和 No supported authentication methods 这两种非常容易让人怀疑是密码敲错了其实往往是配置文件的问题。5. 安全加固别让你的 root 变成靶子5.1 优先用密钥认证而不是密码登录如果这台机器不是在内网调试而是直接暴露在公网我强烈建议你改用密钥认证。原理是密钥是一对非对称加密的字符串私钥留在本地公钥放到服务器上。登录时客户端用私钥签名服务器用公钥验证整个过程不需要传输密码从根本上避免了密码被截获或暴力破解的风险。密钥登录的配置分三步走。第一步在客户端生成密钥对ssh-keygen -t ed25519 -C your_comment这里推荐的算法是 ed25519它的密钥长度短、安全性高、生成速度快新客户端基本都支持。如果你要连接的老系统不支持 ed25519就用 rsassh-keygen -t rsa -b 4096生成过程中会提示你设置 passphrase也就是私钥的解锁密码。建议设置否则私钥文件泄露就等于把服务器拱手让人。第二步把公钥传到服务器上。最稳的是用 ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519.pub root192.168.1.100它会自动把公钥追加到服务器的 ~/.ssh/authorized_keys 文件里并且设置好权限。如果你是在 Windows 上手动操作要确认文件权限正确。authorized_keys 文件权限只能是 600.ssh 目录权限只能是 700权限过宽 SSH 会拒绝使用该密钥。第三步在服务器上测试密钥登录是否成功。成功后再把 PasswordAuthentication 改成 no这样密码登录就被彻底关闭了。同时把 PermitRootLogin 改成 prohibit-password效果是 root 只允许密钥登录。5.2 修改默认端口和限制登录来源默认 22 端口每天会被扫描无数次光靠换端口其实挡不住有耐心的攻击者但能过滤掉大量无脑扫描流量。改端口在 sshd_config 里Port 22222改完之后记得重启服务并把防火墙规则同步更新sudo ufw allow 22222/tcp另一个更有效的办法是限制来源 IP。如果你的客户端 IP 基本固定可以在 sshd_config 里加一行AllowUsers root192.168.1.0/24这样只有来自 192.168.1.0/24 网段的请求才能用 root 登录其他来源一律拒绝。如果你的办公网络 IP 是动态的这个方案会比较痛苦走密钥认证更现实。还有一个手段是安装 fail2ban它会在检测到多次认证失败后自动将来源 IP 加入防火墙黑名单一段时间sudo apt install -y fail2ban默认配置下fail2ban 会对 SSH 服务做监控5 分钟内失败 5 次就封禁 10 分钟。这个工具对公网服务器非常有用几乎是我每次部署 SSH 服务的必装项。5.3 监控登录日志做到心中有数最后一条安全习惯定期看登录日志。Ubuntu 的认证日志记录在 /var/log/auth.log可以用下面的命令快速查看登录历史sudo grep Accepted /var/log/auth.log看到明显不在预期时段、来自陌生 IP 的成功登录那就要提高警惕了。另外查一下用户列表sudo lastlog这个命令能列出所有用户的最近登录时间如果发现有不知道哪里来的用户或者 root 在不该登录的时间登录过就要检查一下账户安全了。老话说得好日志不查等于没记。不需要每天看但至少每周瞄一眼或者设置一个定时任务把关键日志定期发到你的邮箱也算是对自己的提醒。6. 翻车常见问题与排查经验实录6.1 改完配置连不上但我已经在远程操作了这个问题我估计能排进各位踩坑排行榜前两名。场景是你通过 SSH 连服务器改配置改完重启 SSH 服务瞬间断连然后再也连不上。要命的是你不在物理机旁边。解决思路是在重启 SSH 服务之前先建立一个不中断的会话。经典做法是使用 tmux 或 screen 开一个后台会话在里面执行重启命令。即使 SSH 连接断了后台会话里的 shell 还能继续执行命令。等你用别的方式比如云控制台的 VNC 或物理终端重新连上去执行 tmux attach 就能回到原来的终端。我个人的操作习惯是任何涉及 SSH 服务的远程变更都会先开一个 tmux 会话然后在会话里执行配置变更和服务重启。这已经成为肌肉记忆了强烈建议你也养成这个习惯。6.2 配置改了但怎么测都不生效有一种情况特别让人烦躁明明改好了 PermitRootLogin yes也重启了 SSH 服务但连接时还是提示不允许 root 登录。这时候多半是子配置文件覆盖了主配置。前面已经提过 /etc/ssh/sshd_config.d/ 目录这里我再具体说一遍排查方法。执行sudo grep -r PermitRootLogin\|PasswordAuthentication\|PubkeyAuthentication /etc/ssh/sshd_config.d/如果输出里出现了和主配置不一致的设置那就是它在捣乱。Ubuntu 的 cloud-init 经常生成 60-cloudimg-settings.conf 并写入 PasswordAuthentication no很多云服务器用户都会中招。解决办法有两种要么删掉或注释掉子配置文件里的对应行要么把主配置文件的对应选项改成和子配置文件一致。我个人更倾向于修改子配置文件因为不要破坏 cloud-init 的整体结构避免后续更新时出问题。注意Debian 系系统的 SSH 配置读取顺序是先读主配置文件再读 sshd_config.d 下所有以 .conf 结尾的文件后读取的会覆盖先读取的。所以想保证某个配置生效改子配置文件更直接。6.3 密码明明正确却一直 Permission denied这个问题的迷惑性很强。明明在服务器上 sudo passwd root 设置过密码本机测试也能登录但远程就是 Permission denied。这时候要优先考虑 PAM 模块的限制。Ubuntu 的 SSH 服务在收到密码后会交给 PAM 去验证。如果 PAM 的配置里对 root 有限制密码再正确也会被拒绝。查看 /etc/pam.d/sshd 里是否有类似 pam_securetty.so 的配置这个模块会限制 root 只能在特定终端登录而 SSH 对应的终端往往不在白名单里。如果确认是这个问题可以注释掉对应的行。不过这种场景比较少见通常在默认安装下不会触发。更常见的还是前两种先优先排查那些。6.4 服务器能连上但执行命令特别卡这不是登录配置的问题而是 SSH 会话交互迟钝。常见原因是 DNS 反向解析超时。SSH 服务端默认会尝试反向解析客户端 IP如果 DNS 不可用解析超时就会导致连接和命令执行卡顿。解决方法是在 sshd_config 里设置UseDNS no然后重启服务。还有一个办法是在客户端连接时指定 -o GSSAPIAuthenticationno 或 -o ServerAliveInterval60这些都能让连接更清爽。不过最根本的还是在服务端把 UseDNS 关掉。6.5 汇总速查表我把上面这些常见问题整理成一张表方便你以后快速定位症状优先排查项解决路径连接被拒绝服务状态systemctl status ssh连接超时防火墙/网络ufw status、ping、telnet认证失败密码/配置passwd root、sshd_config、子配置覆盖配置不生效子配置覆盖grep sshd_config.d登录卡顿反向 DNSUseDNS no远程改配置断连无备用会话tmux/screen7. 实操总结与我的个人体会整套流程走下来其实就三件事给 root 设密码、改 SSH 配置允许 root 登录、验证并加固。每一步都不复杂但每一步都有容易被忽略的细节。尤其是配置文件子目录覆盖和防火墙拦截这两个点几乎是我见过新手翻车频率最高的地方。从我自己的运维经验来说我确实不建议在日常操作里直接拿 root 登录——sudo 机制是 Ubuntu 的亮点它能让每个操作都留下痕迹。但作为服务器管理员完全封死 root 远程登录又太绝对很多自动化脚本和服务部署还是需要 root 权限的直连。所以我更推荐折中方案平时用普通用户加 sudo 操作特殊需求时再用密钥方式以 root 身份登录。这样既兼顾了安全又保留了灵活性。如果你按照这篇文章操作完还是有问题别慌按顺序重新检查一遍先确认 root 密码是否真的设置成功再确认 sshd_config 里 PermitRootLogin 和 PasswordAuthentication 的值最后检查 sshd_config.d 里有没有覆盖配置再看看 ufw 是否放行了对应端口。九成问题都出在这四个环节里。最后再分享一个我自己的小习惯每次改完 SSH 配置我都会顺手生成一份带日期的备份文件并且把旧的备份定期清理掉。这样既不会把配置改乱也不会积攒一堆没用的历史文件算是给将来的自己留条后路。