Oracle 云主机初始化与安全加固：从新机到可长期使用的基础配置 | 观者终端

如果你已经完成账号注册、区域选择、实例创建和首次 SSH 登录，那么接下来真正决定这台机器能不能长期稳定使用的，往往不是“怎么装服务”，而是“怎么先把基础打牢”。

如果你还没完成前面的步骤，可以先看上一篇 [[2026-03-27-oracle-account-machine-application]]。

Oracle 云主机和其他 VPS 一样，刚创建出来时只是能启动、能连上，并不代表已经适合长期暴露在公网。很多问题不会在部署当天立刻出现，而是在几天甚至几周后才慢慢暴露：默认用户长期裸奔、SSH 配置过于宽松、防火墙规则没有收口、日志没人看、备份没做。一旦机器真正开始承载博客、小服务、代理节点或实验环境，这些隐患都会变成后续的维护成本。

这篇文章不讲花哨配置，只讲一套最实用的基线流程：把一台刚开出来的 Oracle 云主机，整理成一台更适合长期运行的基础服务器。文中的命令以 Ubuntu 为例，Oracle Linux 则可以用对应的 dnf 或系统工具完成同类操作。

为什么 Oracle 新机初始化不能省

很多人会把“能 SSH 登录”误认为“机器已经能放心用了”。但从运维角度看，这其实只是起点，不是终点。

如果你打算把它用作博客服务器、小型服务节点、实验环境或跳板机，初始化阶段至少要先解决下面几件事：

谁可以登录这台机器
机器真正对外开放了哪些端口
系统如何保持基本更新
出问题之后如何排查与回滚

这些事情如果一开始没处理好，后面项目即使部署成功，也很容易在安全性、可维护性和稳定性上埋坑。

首次登录后，先确认机器的基本状态

第一次 SSH 登录上去之后，不要急着装 Docker、面板或其他服务。先看清楚这台机器当前到底是什么状态。

建议先执行下面几组命令：

uname -a
cat /etc/os-release
free -h
df -h
ip a
ip route

重点确认这些信息：

当前系统是不是你预期的 Ubuntu 或 Oracle Linux
内存和磁盘容量是否与控制台里选择的一致
网卡、公网地址和私网地址是否正常
默认路由是否存在

这一步看起来简单，但非常值。很多网络问题、镜像选择问题，或者后续和 Docker、IPv6、代理、面板相关的兼容问题，往往都能在这里提前发现，而不是等部署到一半才回头排查。

创建管理用户，别长期直接用默认用户裸奔

默认用户 ubuntu 或 opc 适合第一次登录和快速验证，但不太适合长期把所有操作都堆在上面。更稳妥的做法，是创建一个你自己的管理用户，并授予 sudo 权限。

以 Ubuntu 为例：

sudo adduser admin
sudo usermod -aG sudo admin

然后把当前公钥复制到新用户目录下：

sudo mkdir -p /home/admin/.ssh
sudo cp ~/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
sudo chown -R admin:admin /home/admin/.ssh
sudo chmod 700 /home/admin/.ssh
sudo chmod 600 /home/admin/.ssh/authorized_keys

做完之后，不要立刻删除默认用户，也不要马上关闭当前会话。先重新开一个终端窗口，验证 admin 是否能正常登录、是否具备 sudo 权限。确认一切正常，再决定默认账号是保留备用还是后续收紧使用范围。

SSH 加固：先保证不断连，再追求更严格

SSH 是管理这台机器最核心的入口，所以加固时最重要的一条原则其实很朴素：先别把自己锁在门外。

更稳妥的顺序通常是：

先确认公钥登录已经可用
再修改 SSH 配置
重启 SSH 前保留一个已经连上的旧会话

常见的基础加固包括：

禁止密码登录
禁止 root 直接登录
只保留密钥认证

编辑配置文件：

sudo nano /etc/ssh/sshd_config

常用配置如下：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

修改完成后，先检查语法：

sudo sshd -t

确认没有报错，再重启 SSH：

sudo systemctl restart ssh

如果你是远程管理唯一的一台机器，建议整个操作过程都保留一个已登录的旧窗口。这样即使新配置有问题，也还有机会回滚，而不是直接被关在外面。

UFW 和 Oracle 安全列表必须一起看

这一步是 Oracle 场景里最容易让人误判的地方。

在 Oracle 上，一个端口能不能从公网访问，通常至少取决于两层：

Oracle 云侧的安全列表或 NSG 是否放行
实例内部的防火墙是否放行

只看其中一层，通常都会得出错误结论。很多人明明看到服务已经在机器上监听了，但外部怎么都连不上，问题往往就是其中一边漏配了。

如果你暂时只需要保留 SSH，可以先这样配置：

sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

如果后面要对外提供 Web 服务，再按需放行：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

然后再回到 Oracle 控制台，检查对应子网、安全列表或 NSG 是否也同步放行了相同端口。记住一个很实用的判断标准：云侧放行和机器内放行，必须同时成立，公网访问才会真正生效。

系统更新、时区与自动安全更新

新机上线后先更新系统，是最基本也最值得做的一步：

sudo apt update && sudo apt upgrade -y

然后确认当前时间与时区，避免后续日志时间混乱：

timedatectl
sudo timedatectl set-timezone Asia/Shanghai

如果这台机器准备长期在线，建议再补上自动安全更新。Ubuntu 下可以这样安装和启用：

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

这样至少关键安全补丁不会长期积压。对于个人维护的小机器来说，这种“低打扰但持续有效”的基础措施，往往比一次性折腾很多复杂组件更划算。

fail2ban：可以上，但别神化

如果 SSH 或 Web 服务直接暴露在公网，fail2ban 仍然是一个成本不高、收益稳定的补充防线。它不能代替密钥登录、防火墙和最小暴露原则，但可以有效减少暴力扫描和撞库带来的噪音。

安装方式很直接：

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

对个人服务器来说，前期其实不用花太多时间细调 jail 规则。先把下面这几层基础防线叠起来，效果通常已经不错：

密钥登录
禁用密码登录
只开放必要端口
启用 fail2ban

真正需要重点关注的，不是把单个工具调到多复杂，而是整体暴露面有没有尽量收小。

日志、备份与快照：给未来的自己留后路

只要这台机器未来还有持续使用价值，就应该尽早想清楚一个问题：如果它坏了，或者你自己改崩了，准备怎么恢复？

最实用的做法，至少包括下面三层。

1. 先学会看基础日志

journalctl -p 3 -xb
sudo systemctl --failed

这能帮助你快速确认系统当前有没有明显报错，哪些服务处于失败状态。

2. 给关键配置留副本

至少建议把这些内容备份下来：

/etc/ssh/sshd_config
当前防火墙规则
你后续部署服务的配置文件
数据目录和挂载位置说明

这些文件平时不起眼，但一旦迁移、回滚或重装，价值会非常高。

3. 利用云侧快照或启动卷备份

如果 Oracle 控制台支持快照或备份策略，建议在完成初始化和第一轮加固之后，留一个“干净基线”快照。这样后面就算装坏了、配崩了，至少还能快速回到一个已知稳定状态，而不是从头再来一遍。

一份实用的上线前检查清单

在真正部署业务之前，可以用下面这份清单快速过一遍：

当这些都完成之后，再去部署 Docker、博客、面板、代理或其他服务，整体会稳很多，也更容易维护。

结语

Oracle 云主机的初始化与安全加固，重点从来不是做一堆看起来很厉害的配置，而是先把最基础、最容易出事故的环节处理好。对大多数个人用户和技术人员来说，真正重要的是四件事：能登录、能维护、能收口、能回滚。

只要你把用户权限、SSH、防火墙、系统更新、日志和备份这些基础项做扎实，这台 Oracle 机器就已经具备了长期使用的基本条件。后面无论你要跑博客、部署小服务、挂 Docker，还是把它整理成长期可用的个人运维节点，都会轻松很多。

如果你想继续写成系列，下一篇也很自然：比如《Oracle 云主机上部署 Docker 与常用服务》，或者《如何把 Oracle 云主机整理成长期可用的个人运维节点》。