Server Ops Maintenance

Operating Model

Treat server changes as live infrastructure work. Prefer evidence first, a reviewed plan second, and explicit execution third.

Identify target host, OS, access method, and whether the current login is root.
Run a read-only audit before proposing changes when shell access is available.
If the audit finds root SSH login, password SSH login, no active firewall, no fail2ban, or similar baseline gaps, recommend the initialization workflow.
Before mutating anything, state the exact blast radius: SSH auth changes, firewall ports, sudo policy, packages, services, and rollback path.
Keep one existing SSH session open while validating a second login session with the new user and key.
Never disable root SSH or password SSH until the new key-based login and sudo path have been verified.

Use Chinese for user-facing summaries unless the user asks otherwise.

Bundled Resources

scripts/audit-linux-security.sh: run on the target server for read-only baseline checks.
scripts/bootstrap-debian-ubuntu.sh: run on Debian/Ubuntu targets to create a sudo user, install a public key, configure SSH hardening, enable UFW, configure fail2ban, install an interactive rm guard, and enable unattended security upgrades.
references/security-baseline.md: read when planning a hardening run, handling non-Debian distributions, or explaining tradeoffs.

Audit Workflow

Use the audit script first:

sudo bash scripts/audit-linux-security.sh

If working over SSH, upload the script to a temporary path such as /tmp/codex-server-audit.sh, run it, collect stdout, and remove it afterward.

Classify results:

Critical: no verified non-root sudo user before SSH hardening, root login allowed with password auth, firewall inactive on a public host.
High: password SSH enabled, fail2ban missing or inactive, SSH config invalid, sudoers misconfigured.
Medium: unattended security updates disabled, persistent journald disabled, weak SSH retry limits, missing time sync.
Info: cloud firewall checks, provider console checks, monitoring and metrics TODOs.

Initialization Workflow

Use this workflow when the user asks to initialize a server or the audit shows baseline security gaps.

Required user inputs:

Target host and current SSH login method.
New admin username.
New admin password, if the OS account should support password login locally.
Public SSH key content or local public key path. Prefer ~/.ssh/id_ed25519.pub if present.
Ports to keep reachable. Default to 22, 80, and 443; include any custom SSH port before enabling the firewall.

Execution order:

Detect OS and package manager. Use the bundled bootstrap script only for Debian/Ubuntu.
Create the new admin user and home directory.
Install the user's SSH public key into ~/.ssh/authorized_keys.
Configure passwordless sudo in /etc/sudoers.d/<user> and validate with visudo -cf.
Write SSH hardening into /etc/ssh/sshd_config.d/99-codex-hardening.conf, then run sshd -t.
Allow required firewall ports before enabling the firewall.
Install and enable fail2ban with a conservative SSH jail.
Install an interactive rm guard under /etc/profile.d/99-codex-rm-guard.sh to protect beginner users from rm -rf /, rm -rf *, rm -rf ./*, deleting $HOME, and similar high-risk delete-all mistakes.
Enable unattended security updates when available.
Reload SSH, then verify a new key-based SSH session and sudo -n true.
Only after verification, keep root account usable locally but ensure PermitRootLogin no for SSH. Do not lock the root account unless the user explicitly asks and recovery access is confirmed.

Debian/Ubuntu Bootstrap

Prefer dry-run first:

sudo bash scripts/bootstrap-debian-ubuntu.sh \
  --admin-user deploy \
  --ssh-public-key-file ~/.ssh/id_ed25519.pub \
  --allow-port 22 \
  --allow-port 80 \
  --allow-port 443 \
  --dry-run

Apply only after the user confirms:

sudo bash scripts/bootstrap-debian-ubuntu.sh \
  --admin-user deploy \
  --ssh-public-key-file ~/.ssh/id_ed25519.pub \
  --allow-port 22 \
  --allow-port 80 \
  --allow-port 443 \
  --apply

If the public key path is local to the operator machine rather than the server, copy the key content into --ssh-public-key.

Safety Rules

Do not run destructive commands such as ufw reset, passwd -l root, or broad iptables -F unless the user explicitly approves and a rollback path exists.
Do not close the current SSH session during hardening.
Do not change the SSH port unless the new port is allowed in both host firewall and cloud firewall.
Do not assume cloud security groups mirror host firewall state; ask the user to verify provider firewall rules if Codex cannot inspect them.
Do not hide failed commands. Surface errors, include the command that failed, and stop before the next risky step.
Before service reloads, validate configs: sshd -t, visudo -cf, fail2ban-client -t when available.
Preserve existing comments in config files. Prefer drop-in files under /etc/ssh/sshd_config.d/, /etc/fail2ban/jail.d/, and /etc/sudoers.d/.
For delete protection, prefer an interactive shell guard in /etc/profile.d/; do not replace /bin/rm, because system scripts and package managers rely on standard rm behavior.

Observability

For every live run, produce a concise operation log:

Target host, OS, kernel, current user, timestamp.
Commands run and whether each was read-only or mutating.
Services changed and final status.
SSH validation result for the new user.
Firewall allowed ports and default policy.
Fail2ban jail status.
rm guard installation status and a note that it applies only to interactive shells.
TODO comments for future tracing or metrics integration when the target stack has an observability agent.

Use Info for successful phase transitions, Warn for detected gaps or skipped hardening, and Error for failed commands or rollback actions.

Non-Debian Targets

Read references/security-baseline.md before acting. Translate the same baseline to the target distribution using native tools:

RHEL/CentOS/Fedora: dnf/yum, firewalld, SELinux-aware changes.
Alpine: apk, OpenRC services, nftables or provider firewall.
Arch: pacman, systemd, ufw or nftables.

For unsupported distributions, audit and propose commands first; do not apply until the user approves the distro-specific plan.