Manual-only gate: If the user did not explicitly invoke vps-setup-hardening by name, stop without inspecting or changing any server. Explain that this skill is manual-only.
VPS Setup and Hardening
Supports exactly two closed profiles:
| Profile |
Host |
Ingress |
ubuntu |
Ubuntu 24.04/26.04 (amd64/arm64) |
No Docker: UFW. Docker: verified provider firewall. |
al2023-ec2 |
Amazon Linux 2023 on positively identified EC2 (x86_64/aarch64) |
EC2 Security Groups for every run. |
Critical rules
- Before connecting to or changing a server, read
references/workflow.md completely and follow its gates in order.
- After read-only inspection, load only the selected profile reference:
references/ubuntu.md or references/al2023-ec2.md.
- Treat invocation arguments and prior conversation as authoritative context. Do not ask the user to repeat a resolved choice or any discoverable fact. Ask only for required non-discoverable information, grouping unresolved choices into one compact question after inspection whenever possible.
- Never request passwords, private keys, provider API tokens, Tailscale auth keys, or other credentials. Do not expose keys, tokens, authentication URLs, or sensitive configuration in reports.
- Preserve the current working session through every SSH, Tailscale, firewall, Security Group, and reboot change. Never remove an access path until its replacement succeeds in a fresh independent test.
- Stop at every human authentication, independent external test, provider/SG change, access-closing action, and reboot gate. Continue only from explicit evidence or confirmation for that gate.
- Never claim provider or Security Group filtering from local server output. Distinguish local observations from user-confirmed provider state.
- Never describe UFW or ordinary host-input filtering as protection for Docker-published ports. Docker always requires a verified provider/SG boundary first.
- Never modify local
~/.ssh/config without separate explicit approval. Prefer command-line overrides for tests.
- Use the bundled profile scripts rather than recreating their deterministic commands. Do not weaken or speculate past a script refusal. Unsupported hosts must fail before mutation.
- Always finish a completed run with verification, cleanup of only the staged temporary bundle, and the report defined by
assets/final-report.md.
Resources and execution
- Before any server action, read
references/workflow.md completely.
- Stage and run the bundled
scripts/ and assets/config/ resources as directed. Invoke profile scripts under scripts/ubuntu/ or scripts/al2023-ec2/ directly—no dispatcher wrappers.
- Immediately before the final response, read
assets/final-report.md and use its brief evidence-qualified structure.
Prefer a native persistent SSH/session capability when available. Otherwise use normal ssh with scp, rsync, or SFTP. Provider consoles and rescue mode are recovery paths, not the default execution path.
Completion contract
A run is complete only when mutations were verified, intended access and exposure were tested independently, any approved reboot was followed by reconnection and repeated checks, staged resources were removed safely, and the final report distinguishes completed work, observed state, user-confirmed external state, incomplete checks, and remaining work.
1---2name: vps-setup-hardening3description: Runs a manually initiated, safety-gated VPS setup and hardening workflow for Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, and Amazon Linux 2023 on EC2. Use this skill when, and only when, the user explicitly invokes vps-setup-hardening by name and supplies a VPS or SSH target, optionally with tool, firewall, access, and runtime preferences. Do not use for ordinary SSH administration, application deployment, compliance auditing, isolated package installation, targeted firewall repair, or automatic infrastructure changes.4license: MIT5---67> **Manual-only gate:** If the user did not explicitly invoke `vps-setup-hardening` by name, stop without inspecting or changing any server. Explain that this skill is manual-only.89# VPS Setup and Hardening1011Supports exactly two closed profiles:1213| Profile | Host | Ingress |14|---|---|---|15| `ubuntu` | Ubuntu 24.04/26.04 (`amd64`/`arm64`) | No Docker: UFW. Docker: verified provider firewall. |16| `al2023-ec2` | Amazon Linux 2023 on positively identified EC2 (`x86_64`/`aarch64`) | EC2 Security Groups for every run. |1718## Critical rules1920- Before connecting to or changing a server, read [`references/workflow.md`](references/workflow.md) completely and follow its gates in order.21- After read-only inspection, load only the selected profile reference: [`references/ubuntu.md`](references/ubuntu.md) or [`references/al2023-ec2.md`](references/al2023-ec2.md).22- Treat invocation arguments and prior conversation as authoritative context. Do not ask the user to repeat a resolved choice or any discoverable fact. Ask only for required non-discoverable information, grouping unresolved choices into one compact question after inspection whenever possible.23- Never request passwords, private keys, provider API tokens, Tailscale auth keys, or other credentials. Do not expose keys, tokens, authentication URLs, or sensitive configuration in reports.24- Preserve the current working session through every SSH, Tailscale, firewall, Security Group, and reboot change. Never remove an access path until its replacement succeeds in a fresh independent test.25- Stop at every human authentication, independent external test, provider/SG change, access-closing action, and reboot gate. Continue only from explicit evidence or confirmation for that gate.26- Never claim provider or Security Group filtering from local server output. Distinguish local observations from user-confirmed provider state.27- Never describe UFW or ordinary host-input filtering as protection for Docker-published ports. Docker always requires a verified provider/SG boundary first.28- Never modify local `~/.ssh/config` without separate explicit approval. Prefer command-line overrides for tests.29- Use the bundled profile scripts rather than recreating their deterministic commands. Do not weaken or speculate past a script refusal. Unsupported hosts must fail before mutation.30- Always finish a completed run with verification, cleanup of only the staged temporary bundle, and the report defined by [`assets/final-report.md`](assets/final-report.md).3132## Resources and execution33341. **Before any server action**, read [`references/workflow.md`](references/workflow.md) completely.352. Stage and run the bundled [`scripts/`](scripts/) and [`assets/config/`](assets/config/) resources as directed. Invoke profile scripts under `scripts/ubuntu/` or `scripts/al2023-ec2/` directly—no dispatcher wrappers.363. **Immediately before the final response**, read [`assets/final-report.md`](assets/final-report.md) and use its brief evidence-qualified structure.3738Prefer a native persistent SSH/session capability when available. Otherwise use normal `ssh` with `scp`, `rsync`, or SFTP. Provider consoles and rescue mode are recovery paths, not the default execution path.3940## Completion contract4142A run is complete only when mutations were verified, intended access and exposure were tested independently, any approved reboot was followed by reconnection and repeated checks, staged resources were removed safely, and the final report distinguishes completed work, observed state, user-confirmed external state, incomplete checks, and remaining work.
maxedapps