企业官网建设流程全解析

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 设了密码，依然没法用密码登录的原因。我们要改成 yes：

PermitRootLogin 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 root@localhost

或者指定端口：

ssh -p 22 root@127.0.0.1

如果一切正常，它会提示你输入密码，输入之前设置的 root 密码，成功后就进入了 root 的 shell。这一步成功了，说明服务端配置没问题，问题如果出在远程连接上，那就是网络或客户端那边的事。

我建议这一步一定要做。很多人在服务器上改完配置直接关掉当前终端，然后从电脑上连，发现连不上，再想回服务器改配置就很麻烦。回环测试能帮你把服务端的问题在本地就排查掉。

4.2 从另一台机器远程连接

在另外一台电脑上，用任意 SSH 客户端连接。Linux 或 macOS 直接用终端：

ssh root@192.168.1.100

Windows 的话，可以用 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 连接失败的常见表现和快速判断

我整理了一张速查表，按症状定位原因，排查效率会高很多：

这些都是我实际踩过的坑。尤其是 Permission denied 和 No supported authentication methods 这两种，非常容易让人怀疑是密码敲错了，其实往往是配置文件的问题。

5. 安全加固：别让你的 root 变成靶子

5.1 优先用密钥认证而不是密码登录

如果这台机器不是在内网调试，而是直接暴露在公网，我强烈建议你改用密钥认证。原理是：密钥是一对非对称加密的字符串，私钥留在本地，公钥放到服务器上。登录时客户端用私钥签名，服务器用公钥验证，整个过程不需要传输密码，从根本上避免了密码被截获或暴力破解的风险。

密钥登录的配置分三步走。第一步，在客户端生成密钥对：

ssh-keygen -t ed25519 -C "your_comment"

这里推荐的算法是 ed25519，它的密钥长度短、安全性高、生成速度快，新客户端基本都支持。如果你要连接的老系统不支持 ed25519，就用 rsa：

ssh-keygen -t rsa -b 4096

生成过程中会提示你设置 passphrase，也就是私钥的解锁密码。建议设置，否则私钥文件泄露就等于把服务器拱手让人。

第二步，把公钥传到服务器上。最稳的是用 ssh-copy-id：

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@192.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 root@192.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 GSSAPIAuthentication=no 或 -o ServerAliveInterval=60，这些都能让连接更清爽。不过最根本的还是在服务端把 UseDNS 关掉。

6.5 汇总速查表

我把上面这些常见问题整理成一张表，方便你以后快速定位：

7. 实操总结与我的个人体会

整套流程走下来，其实就三件事：给 root 设密码、改 SSH 配置允许 root 登录、验证并加固。每一步都不复杂，但每一步都有容易被忽略的细节。尤其是配置文件子目录覆盖和防火墙拦截这两个点，几乎是我见过新手翻车频率最高的地方。

从我自己的运维经验来说，我确实不建议在日常操作里直接拿 root 登录——sudo 机制是 Ubuntu 的亮点，它能让每个操作都留下痕迹。但作为服务器管理员，完全封死 root 远程登录又太绝对，很多自动化脚本和服务部署还是需要 root 权限的直连。所以我更推荐折中方案：平时用普通用户加 sudo 操作，特殊需求时再用密钥方式以 root 身份登录。这样既兼顾了安全，又保留了灵活性。

如果你按照这篇文章操作完还是有问题，别慌，按顺序重新检查一遍：先确认 root 密码是否真的设置成功，再确认 sshd_config 里 PermitRootLogin 和 PasswordAuthentication 的值，最后检查 sshd_config.d 里有没有覆盖配置，再看看 ufw 是否放行了对应端口。九成问题都出在这四个环节里。

最后再分享一个我自己的小习惯：每次改完 SSH 配置，我都会顺手生成一份带日期的备份文件，并且把旧的备份定期清理掉。这样既不会把配置改乱，也不会积攒一堆没用的历史文件，算是给将来的自己留条后路。