使用 Codex Skill 自动运维 OCI 服务器

在人工完成 OCI 实例创建和首次 SSH 后，使用 oracle-cloud-server-operator 对 Debian/Ubuntu 主机执行只读审计、分阶段初始化和独立验证。

#type / howto #status / growing #tech / ops #tech / ai #tech / security #resource / oracle-cloud #platform / server

[!abstract] 自动化边界这个 skill 从“实例已经存在且至少有一个 SSH 入口可用”开始。注册、支付验证、MFA、Home Region、实例创建、OCI NSG 与付费资源仍由人确认；AI 可以接管主机审计、分阶段加固、验证和报告，但不能自行删除实例、卷、备份或最后一个登录入口。

使用 Codex Skill 自动运维 OCI 服务器

Skill 在哪里

仓库路径：

D:\home\projects\skills\skills\oracle-cloud-server-operator

核心文件：

oracle-cloud-server-operator/
├── SKILL.md
├── agents/openai.yaml
├── references/
│   ├── operator-workflow.md
│   ├── security-and-recovery-guardrails.md
│   └── supported-systems.md
└── scripts/
    ├── invoke-oracle-server.ps1
    ├── audit-server.sh
    ├── bootstrap-server.sh
    └── verify-server.sh

Skill 支持 Debian 12、Ubuntu 22.04/24.04 的 amd64 和 arm64 初始化。Oracle Linux 等 RPM 系统当前只允许尽力审计，不执行 Bootstrap。

三种模式分别解决什么

模式	是否修改主机	使用时机	关键输出
`Audit`	否；只在 `/tmp` 临时上传并清理脚本	任何操作之前	OS、架构、资源、端口、SSH、UFW、服务、更新和日志
`Bootstrap -DryRun`	否	查看计划、检查参数	目标用户、端口、CIDR、Docker 和执行阶段
`Bootstrap -Apply`	是	新实例需要初始化时	新用户、密钥、UFW、SSH、Fail2ban、自动更新和可选 Docker
`Verify`	否；只在 `/tmp` 临时上传并清理脚本	加固后、重启后或定期复核	每个安全不变量的 PASS/FAIL

当前 oracle1 和 oracle2 已完成主机加固，不应重复运行 Bootstrap。日常使用 Audit 与 Verify 即可。

前置条件

ssh oracle1、ssh oracle2 均已成功。
私钥保存在本机，不将私钥正文交给 AI；只传文件路径。
OCI MFA、串行控制台和引导卷恢复入口可用。
变更 SSH 端口前，OCI NSG 已同时允许当前端口和目标端口。
要创建新管理员时，已经准备配对的公钥和私钥文件。
已明确可信管理来源 CIDR；动态家庭 IP 不应被伪装成长期固定 /32。

1. 让 Codex 使用 Skill

可以直接提出：

使用 $oracle-cloud-server-operator 审计 ssh oracle2，先只读，不做任何修改。

如果当前 Codex 环境尚未自动发现仓库中的 skill，应显式提供路径：

使用 D:\home\projects\skills\skills\oracle-cloud-server-operator 中的 skill，
对 oracle2 运行 Audit，只报告问题，不修改机器。

不要在提示词中粘贴私钥、密码、Token、MFA 恢复码或 OCI Secret。

2. 对现有两台机器做只读审计

从 skills 仓库根目录执行：

pwsh -NoProfile -File .\skills\oracle-cloud-server-operator\scripts\invoke-oracle-server.ps1 `
  -Mode Audit `
  -HostName oracle1 `
  -InitialUser ubuntu `
  -IdentityFile "$env:USERPROFILE\.ssh\oracle.pem"

将 oracle1 替换成 oracle2 即可审计 ARM 开发机。Audit 应回答：

系统版本和 CPU 架构是否符合预期；
sudo 是否无需交互即可执行审计；
SSH 是否仅允许密钥、禁止 root 和密码；
监听端口是否只有预期服务；
UFW、Fail2ban、自动更新是否健康；
是否存在失败服务、待重启或磁盘压力；
Docker 是否安装及当前容器状态。

审计输出可能含主机名和私网地址，公开分享前必须脱敏。

3. 独立验证当前加固结果

pwsh -NoProfile -File .\skills\oracle-cloud-server-operator\scripts\invoke-oracle-server.ps1 `
  -Mode Verify `
  -HostName oracle2 `
  -InitialUser ubuntu `
  -IdentityFile "$env:USERPROFILE\.ssh\oracle.pem" `
  -Port 22

Verify 不以“脚本退出码为 0”作为唯一证据，而是逐项检查：

sshd -t 通过；
root 与密码登录关闭；
公钥登录开启；
目标端口已配置并监听；
管理员、sudo 和 authorized_keys 正常；
UFW、Fail2ban 正常；
systemd 没有失败单元。

任何 [FAIL] 都应先诊断，不要直接重跑 Bootstrap 覆盖现有配置。

4. 新机器先 DryRun，再分阶段 Bootstrap

对未来新建、尚未加固的 Ubuntu/Debian 实例，先执行：

pwsh -NoProfile -File .\skills\oracle-cloud-server-operator\scripts\invoke-oracle-server.ps1 `
  -Mode Bootstrap -DryRun `
  -HostName NEW_HOST `
  -InitialUser ubuntu `
  -IdentityFile "$env:USERPROFILE\.ssh\oracle.pem" `
  -AdminUser operator `
  -AdminPublicKeyFile "$env:USERPROFILE\.ssh\oracle-operator.pub" `
  -AdminIdentityFile "$env:USERPROFILE\.ssh\oracle-operator" `
  -AdminCidr ADMIN_PUBLIC_IP/32 `
  -TargetSshPort 22

审阅计划并在动作发生前明确确认，才把 -DryRun 换成 -Apply。默认保留 22 端口；改端口只减少扫描噪声，不是主要安全措施。

Bootstrap 使用事务式顺序：

备份 SSH 配置并创建管理员；
同时允许当前端口和目标端口；
从本机发起第二个独立 SSH 会话；
只有新管理员与 sudo 验证成功，才关闭 root、密码和交互式认证；
再次验证；
仅在显式指定 -RetireInitialPort 时移除旧端口。

[!warning] 权限模型自动管理员默认获得 passwordless sudo，其私钥等同 root 凭据。启用 Docker 后，docker 组成员同样具有近似 root 的能力。不能把这些权限描述成“普通用户”。

5. OCI 云侧仍需人工配合

Skill 不会修改 OCI NSG、Security List、Reserved Public IP、Budget 或备份策略。执行主机变更前，应先完成完成实例加固后的 OCI 控制台配置。

特别是端口变更必须遵循：

OCI 先放行新端口
→ UFW 放行新端口
→ sshd 同时监听新旧端口
→ 新客户端会话成功
→ 重启后再验证
→ 最后移除旧端口

6. Run Command 只能作为条件式恢复入口

Oracle Cloud Agent 已安装不代表所有插件都支持当前镜像。Oracle 当前的 Run Command 支持平台镜像列表没有 Ubuntu，因此两台 Ubuntu 24.04 机器不能预设 Run Command 一定可用。

恢复顺序：

保留的现有 SSH 会话；
OCI Console History 与指标；
只有实例页面确实显示受支持且 Running 的 Run Command 时才使用；
串行控制台；
停机后挂载引导卷到救援机；
从可信备份重建。

详见 OCI 服务器生命周期与恢复阶梯。

7. 当前双机应如何使用

`oracle1` 代理节点

定期 Audit/Verify；
部署代理服务前记录新监听端口；
只把 80/443 对公网开放；
SSH 来源在建立 VPN 或固定入口后收紧；
1 GB 内存节点避免堆叠构建、数据库和重型监控。

`oracle2` 开发节点

定期 Audit/Verify；
安装开发工具或 Codex CLI 前先输出精确变更计划；
项目服务默认监听 localhost 或私网；
数据库、Redis、Docker daemon 不对公网开放；
建立 oracle1 跳板或 VPN 后，再移除开发机公网地址。

验收记录

Skill 仓库验证器通过。
skill-creator 的 quick_validate.py 通过。
PowerShell 和三个 Bash 脚本语法检查通过。
合法 CIDR DryRun 成功，非法前缀被拒绝。
oracle1 AMD64 Audit 和 Verify 成功。
oracle2 ARM64 Audit 和 Verify 成功。
所有远端 /tmp/codex-oci-* 临时文件已清理。

使用 Codex Skill 自动运维 OCI 服务器

Skill 在哪里

三种模式分别解决什么

前置条件

1. 让 Codex 使用 Skill

2. 对现有两台机器做只读审计

3. 独立验证当前加固结果

4. 新机器先 DryRun，再分阶段 Bootstrap

5. OCI 云侧仍需人工配合

6. Run Command 只能作为条件式恢复入口

7. 当前双机应如何使用

oracle1 代理节点

oracle2 开发节点

验收记录

Related notes

`oracle1` 代理节点

`oracle2` 开发节点