拿到一台刚装好的 Ubuntu 24.04.3 LTS很多人第一件事就是想用 root 账户直接 SSH 远程登陆上去装环境、传文件、跑脚本结果敲下ssh root服务器IP那一刻直接被拒密码明明觉得是对的却始终登不进去。这不是你人品问题而是 Ubuntu 一直以来的安全策略在“挡路”。这篇文章就围绕 Ubuntu 24.04.3 LTS 下开启 root 账户 SSH 远程登陆这件事把原理、操作、踩坑、加固一次讲透。先说清楚这篇内容适合谁刚接触 Ubuntu 服务器、需要在本地终端用 root 身份管理远程主机的开发者或者公司内网测试机只想图省事直接 root 干活的人也包括卡在“SSH 连不上”“PermitRootLogin 改了没用”“密码正确还报 Permission denied”这些问题上需要查漏补缺的朋友。我会把完整的操作步骤、配置项解释和排查思路都写出来大家可以直接照着抄。1. 为什么 Ubuntu 默认不让 root 直接 SSH 登录1.1 默认行为背后的安全设计Ubuntu 从很早的版本开始就默认禁用了 root 账户的密码登录这跟 CentOS 那种“装完就有 root 密码、可以直接 SSH”的体验完全不一样。你在安装 Ubuntu 24.04.3 LTS 时设置的那个用户属于 sudo 用户组日常操作靠sudo提权就够用了而 root 本身没有可用的密码——/etc/shadow里 root 那一行是!或*表示密码锁死。SSH 服务端的默认配置里也有一道坎。/etc/ssh/sshd_config中默认写着PermitRootLogin prohibit-password这个参数的意思是root 可以通过 SSH 登录但不能用密码登录。哪怕你手动给 root 设了密码只要这个配置不改成yes用密码登 root 依然会被拒绝这就是很多人“明明密码没错却登不进去”的根源。这么设计的原因不难理解root 是系统里权限最大的账户如果允许 root 直接拿密码远程登录攻击者就可以对着 22 端口无休止地爆破。而 Ubuntu 默认的 sudo 机制既能让日常管理不别扭又能把 root 的暴露面降到最低。1.2 既然有 sudo为什么还要开 root SSH有人会问日常操作用sudo不就行了何必非要开 root 远程登录我自己的使用场景主要有三类。第一是自动化脚本和批量操作很多部署脚本里大量写scp、rsync、ansible如果目标机器的用户是普通用户文件权限和目录归属会搞得非常别扭直接用 root 最简单省得每步操作都还要考虑提权。第二是某些云主机或内网虚拟机业务系统已经固定用 root 跑用普通用户登录再su -切来切去纯粹浪费时间。第三是一些嵌入式设备、边缘网关系统里本来就没建多个用户root 就是唯一的管理入口。不过我也得提醒一句开 root SSH 之前先想清楚这台机器是“测试机”还是“生产机”。测试机你随便搞生产机建议至少配合密钥登录和端口限制后面第 5 章我会专门讲怎么加固。2. 动手前的环境检查2.1 确认版本和 IP虽然标题写的是 Ubuntu 24.04.3 LTS但下面的方法对 22.04、20.04 其实也通用。先确认一下系统版本别稀里糊涂把命令敲错了cat /etc/os-release lsb_release -a然后查一下这台机器的 IP方便后面的 SSH 连接测试ip addr show如果机器上有多个网卡记得区分内网 IP 和公网 IP。你本地 SSH 连的是哪个 IP后面测试就用哪个。2.2 检查 SSH 服务是否安装Ubuntu Server 版安装的时候如果选了最小化很可能根本没装 SSH 服务端。很多朋友在这步就卡住了ssh命令本地能用但那是因为装了客户端服务端完全是另一回事。先看服务状态systemctl status ssh如果提示Unit ssh.service could not be found说明没装服务端。直接安装sudo apt update sudo apt install -y openssh-server装完之后启动并设置开机自启sudo systemctl enable --now ssh sudo systemctl status ssh注意Ubuntu 上 SSH 服务的 unit 名是ssh不是sshd。很多从 CentOS 转过来的人习惯敲systemctl status sshd在 Ubuntu 上会提示找不到服务其实服务是好的只是名字不一样。可以用systemctl status ssh查看。2.3 备份配置养成好习惯接下来要改的是/etc/ssh/sshd_config。改系统配置之前我习惯先留个备份万一改坏了还能快速还原sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F)另外还要提醒一句Ubuntu 的 SSH 配置现在不只有主文件这一个地方/etc/ssh/sshd_config.d/目录下可能还有别的配置片段。尤其是云服务器、虚拟机镜像经常会有50-cloud-init.conf这种文件它们会在 SSH 服务启动时被主文件用Include指令加载进来。如果你只改了主文件却被这个目录下的片段覆盖掉再怎么改都不会生效。这个坑非常大后面会专门讲。3. 开启 root 账户 SSH 登录的核心操作3.1 给 root 设置一个可用的密码先给 root 设置密码否则后面一切白搭sudo passwd root系统会提示输入两次新密码输入的时候终端不会显示任何字符这是正常现象不是键盘坏了。设置完之后可以验证一下sudo grep root /etc/shadow如果看到 root 行里有$6$或$y$这类哈希串说明密码已经写入成功。这里没有复杂的参数需要解释唯一要注意的是密码尽量别用纯数字、别用键盘连续键后面我还会讲为什么。也有一些人习惯用sudo su -切到 root再输入passwd直接改效果一样看个人习惯。3.2 修改 sshd_config 配置注意 drop-in 覆盖现在到了最关键的一步。按最直接的方式编辑/etc/ssh/sshd_config找到PermitRootLogin这一行改掉sudo nano /etc/ssh/sshd_config把PermitRootLogin prohibit-password改成PermitRootLogin yes如果用密码登录还要确认PasswordAuthentication是yesPasswordAuthentication yes但你千万别急着重启服务先把下面这步做了检查一下/etc/ssh/sshd_config.d/下有没有50-cloud-init.conf之类的文件ls -l /etc/ssh/sshd_config.d/如果有打开看看内容cat /etc/ssh/sshd_config.d/50-cloud-init.conf我见过不少云镜像里这个文件写着PasswordAuthentication yes PermitRootLogin prohibit-password这种情况下就算你改了主配置文件这个片段也会在启动时覆盖你的设置结果就是你折腾半天 root 还是登不进去。正确的做法是在/etc/ssh/sshd_config.d/下新建一个自己的配置片段让它最后被读取。文件名建议用99-开头数字越大越靠后覆盖优先级越高sudo nano /etc/ssh/sshd_config.d/99-root-login.conf写入PermitRootLogin yes PasswordAuthentication yes保存后退出。这样不管50-cloud-init.conf里写的是什么你的99-配置都会在它之后生效。用下面这条命令可以验证最终生效值sudo sshd -T | grep -E permitrootlogin|passwordauthenticationsshd -T会把当前配置解析后的实际效果打出来这个命令非常有用。如果输出是permitrootlogin yes和passwordauthentication yes说明配置已经正确加载。3.3 重启 SSH 服务并验证配置改完一定要重启 SSH否则不生效sudo systemctl restart ssh重启前也可以用sshd -t检查一下语法避免写错导致服务起不来sudo sshd -t没有输出就是没问题。然后本地终端尝试登录ssh root192.168.1.100输入刚才设置的 root 密码如果能成功登进去恭喜你最核心的部分已经完成了。注意如果你改完配置、重启完服务之后发现 SSH 连接直接被拒绝或者提示Connection closed不要慌大概率是配置语法有误或者你把PermitRootLogin写成了prohibit-password之外的错误写法比如without-password这个写法在老版本里能识别新版本 OpenSSH 里其实已经不太推荐。用前面提到的sudo sshd -T检查一下立刻就能定位。3.4 防火墙放行与云安全组检查很多情况下配置全对了但 SSH 还是连不上问题出在防火墙。Ubuntu 自带的是ufw先看状态sudo ufw status如果状态是active需要放行 22 端口sudo ufw allow 22/tcp如果是云服务器还要检查控制台里的安全组规则。Linux 系统内的防火墙只是第一层云厂商安全组相当于第二层两层都放行才能连上。这里没有复杂的参数就一句话系统防火墙、云安全组都要放行 TCP 22 端口。4. 更推荐的方案root 使用 SSH 密钥登录4.1 为什么我建议你用密钥而不是密码把PermitRootLogin改成yes确实能立刻解决问题但从安全角度讲root 密码长期暴露在网络上总归是个隐患。哪怕你密码设得再复杂也架不住爆破、撞库和钓鱼。所以更稳妥的做法是root 依然可以远程登录但只用密钥不用密码。这对应的是默认配置里的prohibit-password展开意思是“密钥可以密码不行”。你平时登录用自己的私钥安全性和便利性都能兼顾。用 DeepSeek 的类比来说密码相当于你家的门锁钥匙只要复制一把就能进屋密钥相当于带芯片的门禁卡别人捡了也没法直接用而且你随时可以挂失换卡。4.2 生成密钥对并分发公钥在本地机器不是服务器上生成密钥对ssh-keygen -t ed25519 -C rootubuntu-24.04 -f ~/.ssh/id_ed25519过程中的提示直接回车即可如果想给私钥再加个口令保护也可以设置 passphrase。生成之后你会看到两个文件id_ed25519是私钥绝不要泄露id_ed25519.pub是公钥需要放到服务器的 root 账户下。分发公钥最简单的方式是ssh-copy-idssh-copy-id -i ~/.ssh/id_ed25519.pub root192.168.1.100如果当前 root 的密码登录还开着这条命令输一次密码就能把公钥自动追加到服务器的/root/.ssh/authorized_keys里。如果出于某种原因用不了ssh-copy-id也可以手动操作。先在本机查看公钥内容cat ~/.ssh/id_ed25519.pub复制整行内容然后在服务器上手动创建文件sudo mkdir -p /root/.ssh sudo touch /root/.ssh/authorized_keys sudo chmod 700 /root/.ssh sudo chmod 600 /root/.ssh/authorized_keys再把公钥内容粘贴进authorized_keys。这里权限非常重要authorized_keys如果权限太宽松SSH 服务会直接忽略它。700和600是标准配置建议严格遵循。4.3 验证密钥登录并关闭密码登录改配置前先验证一下密钥能不能登录ssh -i ~/.ssh/id_ed25519 root192.168.1.100能直接登进去说明密钥已经生效。此时再回到/etc/ssh/sshd_config.d/99-root-login.conf把配置改成PermitRootLogin prohibit-password PasswordAuthentication no然后重启 SSHsudo systemctl restart ssh重启之后再用ssh root192.168.1.100测试注意这次不要带-i参数如果默认用的不是这把私钥可能会登录失败。确认密钥登录没问题了密码登录就彻底关掉了。4.4 VSCode 等工具的 SSH 连接配置现在很多人已经不用命令行终端连服务器了直接用 VSCode 的 Remote-SSH 插件。配置其实很简单打开 VSCode按F1输入Remote-SSH: Open SSH Configuration File在~/.ssh/config里添加Host ubuntu-root HostName 192.168.1.100 User root Port 22 IdentityFile ~/.ssh/id_ed25519保存后F1输入Remote-SSH: Connect to Host选择ubuntu-root就能连上。如果前面已经把密码登录关掉了这里IdentityFile要指向你的私钥路径VSCode 会通过私钥完成认证。5. 常见踩坑场景与排查实录5.1 现象速查表我把实际中遇到的典型问题整理成一个速查表方便你遇到问题时对号入座。现象可能原因解决办法ssh: connect to host ... port 22: Connection refusedSSH 服务没装或没启动端口被改检查systemctl status ssh确认端口号Permission denied (publickey,password)root 密码没设PermitRootLogin 配置不对drop-in 覆盖检查/etc/shadow用sshd -T看实际配置连接超时卡住不动防火墙拦截云安全组未放行IP 地址错误检查ufw status控制台安全组规则改了配置不生效同时存在多个配置片段sshd 没重启检查/etc/ssh/sshd_config.d/重启服务密钥登录被拒绝authorized_keys权限过大私钥不匹配确认700/600权限检查客户端私钥路径Connection closed by ... port 22配置语法错误sshd_config里写错参数sudo sshd -t检查语法查看/var/log/auth.log5.2 “Permission denied”与配置覆盖逻辑这是出现频率最高的问题。我见过有人改了主文件里的PermitRootLogin yes密码也设了但死活登不上。一查发现/etc/ssh/sshd_config.d/50-cloud-init.conf里写着prohibit-password把主文件的设置覆盖了。这里要理解 SSH 配置的加载顺序sshd_config主文件开头的Include /etc/ssh/sshd_config.d/*.conf会把所有conf片段按文件名排序读取后面的设置覆盖前面的。所以只要存在50-cloud-init.conf这类文件主文件里的同项配置就会被它冲掉。解决办法就是在同一目录下建一个更大的数字开头的文件比如99-root-login.conf用它来收尾覆盖。验证命令永远是那句sudo sshd -T | grep -i permitroot看到实际输出是yes才算真的改成功。5.3 防火墙和云安全组的双重检查“连接超时”这个问题也很经典。系统内部ufw明明放行了 22 端口但远程还是连不上尤其是用了云服务器的人经常忘了控制台里的安全组规则。安全组是云平台层面的虚拟防火墙它放行的规则独立于操作系统内部。有的安全组默认只放行 80/443你要连 SSH 还得手动添加一条“允许 TCP 22”。排查顺序建议这样先本地看ufw status然后看systemctl status ssh确保服务在跑最后去云厂商控制台看安全组。如果机器是 VMware 虚拟机那就不涉及安全组直接检查虚拟网络和宿主机防火墙即可。还有一种情况是端口被改了比如有人为了安全把 SSH 改到了 2222你自己忘了客户端还在连 22自然就是Connection refused。5.4 忘记 root 密码的应急恢复有人在开完 root SSH 之后过了一段时间把 root 密码忘了导致远程登录也进不去。这个问题说大不大说小不小如果你本地有 sudo 用户直接sudo passwd root重置即可。但如果是这台机器只有远程 SSH 一个入口而且 root 密码又忘了那就要到物理控制台或者虚拟机管理界面操作了。Ubuntu 系统启动时在 GRUB 菜单选择 advanced options进入 recovery mode然后选择root进入单用户 shell。注意此刻根文件系统通常是只读的需要重新挂载mount -o remount,rw / passwd root执行完passwd重设密码然后重启系统就能恢复 root 登录。需要注意的是恢复模式默认可能会提示“Continue to boot”别选那个选 root shell 进入命令行。5.5 排查日志的位置很多人排查 SSH 问题喜欢乱猜其实最好的办法是看日志。Ubuntu 的 SSH 认证日志在/var/log/auth.log出问题时去看两眼很多答案立刻就有了sudo tail -50 /var/log/auth.log你会看到类似Failed password for root ...、Connection closed by authenticating user root ...等记录这些日志能精确告诉你认证在哪一步失败了。保持这个习惯能让排查效率提升一大截。6. 安全加固与日常使用的建议6.1 降低 root 远程登录风险的三板斧root 远程登录本来就是一件“方便但招风”的事既然开了就得有对应的安全策略。我给自己的服务器定的三条规矩也分享给大家。第一能用密钥就不用密码。把PasswordAuthentication关掉仅保留密钥登录。这样就算有人拿到你的 IP也没法靠猜密码进来。第二修改默认端口。把 SSHH 端口从 22 改成高位端口比如 2222。这能自动过滤掉大量扫描 22 端口的脚本攻击虽然称不上绝对安全但能把噪音降一大截。改完记得同步防火墙和安全组的端口规则sudo nano /etc/ssh/sshd_config # 找到 Port 22 改成 Port 2222 sudo systemctl restart ssh第三限制登录来源。如果服务器只服务于固定的办公 IP可以在安全组上直接限制源 IP这是最粗暴也最有效的办法。系统内部也可以用AllowUsers限制允许 SSH 登录的用户比如AllowUsers root admin这样只有 root 和 admin 两个用户能登录其他账户就算有密码也进不来。6.2 fail2ban 与日志观察如果还是觉得不放心可以装一个fail2ban它会自动监控认证日志发现多次失败的 IP 就临时封禁一段时间sudo apt install -y fail2ban安装之后它会默认读取/var/log/auth.log配合 SSH 的 jail 规则自动生效。配置不用大改默认设置就能挡住不少爆破尝试。这个工具不复杂但对安全有很大的提升建议有条件的都装上。另外定期扫一眼 SSH 登录日志也是一种好习惯sudo grep Accepted password for root /var/log/auth.log | tail -20看看有没有非预期的成功登录。如果是自己的操作记录那没问题如果确实有异常就要立刻排查了。6.3 我实际使用中的教训最后讲一个我自己踩过的坑。有一台内网测试服务器我图省事把PermitRootLogin yes设好就扔在那儿了密码用了一个稍微复杂一点的组合。一周之后看日志发现从凌晨开始就有来自外网的 IP 在持续爆破虽然没成功但看着那些记录心里还是挺膈应的。后来我改成密钥登录改端口日志里爆破的噪音立刻少了很多。所以我的建议是如果这台机器是临时测试机改PermitRootLogin yes没问题但最好还是配合一个强密码如果这台机器有公网 IP、或者会跑长期业务那就老老实实按第 4 章的密钥方案来配置。root 权限一旦暴露在外安全性只能靠多一层防护多一分安心来换。