Linode VPS 初始安全配置：更新系统、SSH 密钥与防火墙

· 更新于 · Linode、Linux教程

Linode VPS 安全配置

新开通 Linode 后，应先确认镜像状态、更新系统、建立可审计的日常管理员账号，再收紧 SSH 和防火墙。顺序很重要：任何可能中断远程连接的修改，都要先准备 Lish、保留现有会话，并从第二个终端验证新连接。

新服务器的初始化状态取决于镜像、创建时提供的 SSH 密钥、cloud-init 和实例能力。不要假定已经安装 BBR、面板或完成安全加固；先读取现状，再应用与当前发行版相符的步骤。

本文以当前 Ubuntu Server 为命令示例。Debian、AlmaLinux、Rocky Linux 等系统的软件包、管理员组、防火墙和服务名称可能不同，应改用对应发行版的官方文档。

变更前准备恢复入口

  1. 在 Cloud Manager 打开并验证 Lish Console，确保公网 SSH 失败时仍能登录。
  2. 保留当前 root/管理员 SSH 会话，不要在全部验证完成前关闭。
  3. 打开第二个终端，后续专门用于测试全新的 SSH 连接。
  4. 记录当前 SSH 端口、Cloud Firewall、主机防火墙和有效配置：
sudo sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '
sudo ss -lntp

第一步：首次 SSH 登录并更新系统

ssh root@你的服务器IP

登录后先刷新软件包索引，再阅读待升级内容：

sudo apt update
apt list --upgradable
sudo apt upgrade

升级可能涉及配置文件选择、内核或服务重启，不要用 -y 跳过生产机上的确认。更新完成后检查失败服务：

systemctl --failed

如果系统提示需要重启，先记录下来，不要在管理员密钥、SSH 配置和防火墙的新连接尚未验证时执行。本文在完成访问路径验证后再安排重启。

第二步：创建日常管理员用户

将示例用户名 deploy 替换为自己的管理员账号：

sudo adduser deploy
sudo usermod -aG sudo deploy

验证 sudo 权限：

su - deploy
sudo whoami
# 应输出: root

不要共享一个管理员账号给多人。每位管理员应使用独立账号和独立公钥，以便撤销和审计。

第三步：配置并验证 SSH 密钥

在本地生成密钥（如果还没有）：

ssh-keygen -t ed25519 -C "your_email@example.com"

为私钥设置安全口令，并把私钥保留在本地；服务器只接收 .pub 公钥。

将公钥上传到服务器：

ssh-copy-id deploy@你的服务器IP

保持原会话不动，在第二个终端验证密钥和 sudo：

ssh -o PasswordAuthentication=no deploy@你的服务器IP
sudo whoami

只有新连接成功且 sudo whoami 输出 root，才能继续禁用密码或 root SSH 登录。

第四步：用独立片段加固 SSH

Ubuntu 支持 /etc/ssh/sshd_config.d/ 配置片段。先检查主配置是否包含该目录，再创建一个排序靠前的本地片段：

sudo grep -n '^Include' /etc/ssh/sshd_config
sudo nano /etc/ssh/sshd_config.d/00-local-hardening.conf

示例内容：

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

如果服务器依赖密码登录、自动化账号或 Linode Managed，应先确认相应访问方式，不能机械复制全部设置。AllowUsers 也不应作为通用模板，否则可能把其他合法管理员或自动化账号排除。

保存后先做语法检查并核对最终生效值：

sudo sshd -t
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

只有 sshd -t 无输出且最终值符合预期时，才在 Ubuntu 上重新加载服务：

sudo systemctl reload ssh.service

继续保留原会话，并在第二个终端再次建立全新密钥连接。如果失败，通过原会话或 Lish 删除本地片段、执行 sudo sshd -t，再 reload 恢复。

不同发行版的服务名与 socket activation 行为可能不同；不要把 systemctl restart sshd 当成所有系统通用命令。

第五步：按实际端口配置 UFW

先读取实际 SSH 端口，不要假定 /etc/services 中的 ssh 别名一定与当前配置相同：

sudo sshd -T | grep '^port '
sudo ufw status verbose

下面以输出为 port 22 的 Web 服务器为例。若 SSH 不是 22，必须先替换成实际端口；80/443 也只在确实提供公网 Web 服务时开放：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw status numbered

保存当前 SSH 会话，确认 SSH 和业务端口规则都存在后再启用：

sudo ufw enable
sudo ufw status verbose

UFW 启用后立即从第二个终端建立全新 SSH 连接，并从真实用户网络测试必要端口。若失败，使用原会话或 Lish 修正规则；不要通过清空全部规则隐藏问题。

Cloud Firewall 是平台网络层，UFW 是实例内的主机防火墙。流量需要同时通过 Cloud Firewall 与主机防火墙；修改一层不会自动同步另一层。Cloud Firewall 的可回滚配置流程见专门指南。

UFW 防火墙状态

第六步：按需安装 Fail2Ban

已经只允许密钥登录并限制 SSH 来源时，Fail2Ban 的收益可能有限；仍需要根据日志封禁重复失败来源时，再安装并使用独立覆盖文件：

sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.d/sshd.local

以下示例仍以 SSH 端口 22 为例，应替换成 sshd -T 显示的实际端口：

[sshd]
enabled = true
port = 22

先验证配置，再启动并检查 jail：

sudo fail2ban-client -t
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

不要把整个 jail.conf 复制成 jail.local；这样会复制大量发行版默认值，后续升级和排错更困难。封禁阈值、可信来源和日志后端应根据实际登录方式与发行版设置。Fail2Ban 也不能替代密钥认证、防火墙、补丁或日志告警。

第七步：在访问路径验证后完成必要重启

如果第一步的系统更新明确提示需要重启，此时应已经完成密钥、sshd 和 UFW 的第二终端验证。再次确认 Lish 可用，在维护窗口执行：

sudo reboot

重启会正常关闭原 SSH 会话。系统恢复后，先从第二个终端以密钥重新登录，检查 SSH 实际端口、UFW、失败服务与业务端口；不要因为旧会话已消失就跳过重启后的验证。若公网 SSH 失败，立即使用 Lish 检查启动日志、sshd 与防火墙配置。

第八步：建立持续维护

初始加固不是一次性操作。至少还应：

安全加固检查清单

通过 iVPSer 自助开通 Linode

iVPSer 提供中文控制台，并支持支付宝、微信和账户余额付款。机房、套餐、操作系统和库存均以实时结算页为准；系统安全配置、应用维护与数据备份由客户负责。

👉 带入 Linode 产品线查看实时报价

参考链接