Prompt Zero

You are Claude Code on the user's machine. The user has a fresh Ubuntu 24.04 server from a cloud
provider, the SSH public key from this machine was added when the server was created, and
`ssh vps` currently logs in as root.

Harden that server end to end: one non-root login user with sudo, key-only SSH, a default-deny
firewall with 22, 80 and 443 open, automatic security updates, Docker Engine with the Compose
plugin, and Caddy running under systemd. Verify every block before starting the next one, and
finish by printing a checklist of what changed.

Run every command on the server over `ssh vps` unless a step says otherwise. Blocks 1 to 5 run as
root. From block 6 on, `ssh vps` logs in as <USER> and anything touching /etc carries `sudo`.

Never print, echo, or repeat in your summary the contents of any key, keyfile, or credential on
either machine.

## 1. Preflight

If <USER> is still literal, ask the user once what to call their login account, then stop until
they answer. Lowercase letters and digits, no spaces, not `admin`, not `root`.

```bash
grep PRETTY_NAME /etc/os-release
uname -m
id -un
ls -A /srv
```

Assert: the release is Ubuntu 24.04, the architecture is x86_64 or aarch64, and `id -un` prints
`root`. If the login is not root, ask the user which account the provider gave them and stop.

If `ls -A /srv` prints anything, or the user says this box already runs something they care
about, stop and say so. This prompt assumes a server whose total loss would cost nothing.

## 2. Update the system

```bash
apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -y upgrade
test -f /var/run/reboot-required && echo REBOOT-NEEDED || echo no-reboot-needed
```

If the last line printed REBOOT-NEEDED, reboot now with `reboot`. That ends the connection. Wait
about 30 seconds, then open a new one and check:

```bash
ssh vps 'uptime -p'
```

Assert: it answers, and reports minutes rather than days. Rebooting here costs 30 seconds.
Rebooting after nine services are installed costs an argument about which one failed to come back.

## 3. Create the login user

```bash
adduser --disabled-password --gecos "" <USER>
usermod -aG sudo <USER>
install -d -m 700 -o <USER> -g <USER> /home/<USER>/.ssh
install -m 600 -o <USER> -g <USER> /root/.ssh/authorized_keys /home/<USER>/.ssh/authorized_keys
```

Give that account sudo without a password prompt, and validate the file before anything depends
on it:

```bash
echo "<USER> ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/90-<USER>
chmod 440 /etc/sudoers.d/90-<USER>
visudo -c -f /etc/sudoers.d/90-<USER>
id <USER>
wc -l < /home/<USER>/.ssh/authorized_keys
```

Assert: `visudo -c` prints `parsed OK`, `id` lists the `sudo` group, and the key file has at
least one line. A malformed file under /etc/sudoers.d breaks sudo for every account on the box,
which is why it is checked in the same block that writes it.

The account has no password, on purpose. SSH becomes key-only two blocks from now, so a password
would be an unused secret sitting in a password manager. Tell the user in one sentence: their SSH
key is the only credential to this server, sudo will not ask them for anything, and the key
belongs on their laptop with a passphrase and nowhere else.

## 4. Firewall

Open 22 in the same block that enables the firewall, before enabling it. `ufw enable` under a
default-deny policy with no SSH rule ends the session and does not give it back.

```bash
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
ufw status verbose
```

22 is the only way in. 80 is where the certificate challenge arrives, and where Caddy answers with
a redirect to HTTPS. 443 is where every app the user installs will answer.

Assert: the output contains `Status: active`, `deny (incoming)`, `allow (outgoing)`, and allow
rules for 22, 80 and 443 and nothing else. Application and database ports never appear in this
list for the life of the server: they bind to 127.0.0.1 in compose, and Caddy reaches them there.

## 5. STOP before the door closes

The next block turns off password authentication and root login. If the new account cannot get in
yet, that block locks the user out of their own server. This is the most common way a first VPS
dies, and the order of these two steps is the entire difference.

STOP: tell the user to do these three things in a second terminal window, and wait. Do not
continue until they confirm all three.

1. Open ~/.ssh/config and change `User root` to `User <USER>`.
2. Run `ssh vps`. It must log in, and `whoami` must print <USER>.
3. In that same session run `sudo -n true; echo $?`. It must print `0`.

If any of the three fails, fix it here, in this block. Do not proceed on the basis that it will
probably work.

Then state the recovery path once, so the stakes are clear rather than frightening: if a later
step does lock them out, the provider's web console still reaches the machine, and rebuilding this
server from scratch takes about a minute, because nothing on it is theirs yet.

## 6. Key-only SSH

```bash
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-hardening.conf
sudo sshd -t
sudo systemctl restart ssh
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|kbdinteractiveauthentication) '
```

Assert: `sshd -t` prints nothing and exits 0, and the last command prints
`passwordauthentication no`, `permitrootlogin no` and `kbdinteractiveauthentication no`. Running
`sshd -t` before the restart is the whole safety net here: a typo in that file plus a restart is a
locked door with no error message.

Open a new connection and prove the door still opens:

```bash
ssh -o BatchMode=yes vps 'whoami'
```

Assert: it prints <USER>. Sessions that are already open survive the restart, so a fresh
connection is the only honest test.

SSH stays on port 22. Moving it reduces log noise and nothing else, and it breaks every tool that
assumes the default.

## 7. Automatic security updates

```bash
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y unattended-upgrades
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run -v | tail -3
```

Assert: 20auto-upgrades contains `APT::Periodic::Update-Package-Lists "1";` and
`APT::Periodic::Unattended-Upgrade "1";`, and the dry run exits 0. If either line is missing or
set to 0, write the file and re-read it:

```bash
sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
cat /etc/apt/apt.conf.d/20auto-upgrades
```

Automatic reboots stay off. Security patches install themselves; a kernel update that needs a
reboot waits for the user. An unattended 3am reboot during a database write is a worse outage than
a kernel that is a week old. Tell the user to run `cat /var/run/reboot-required` when they log in,
and to reboot when it says something.

## 8. Docker Engine and the Compose plugin

From Docker's apt repository, with its signing key on disk. Not a script piped into a shell: apt
gives a signed repository, one upgrade path, and packages the distribution can account for.

```bash
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list >/dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker <USER>
```

```bash
sudo systemctl is-enabled docker
sudo systemctl is-active docker
sudo docker version --format 'server {{.Server.Version}}'
sudo docker compose version
```

Assert: `enabled`, `active`, and both versions print. Record both version strings for block 12.

Group membership only applies to new sessions, so confirm it the way the user will meet it:

```bash
ssh vps 'docker compose version'
```

Assert: a version prints, with no `sudo` and no permission error. If it reports permission denied
on /var/run/docker.sock, that session predates the group change; open another one.

Tell the user plainly: membership in the `docker` group is equivalent to root on this server,
because anyone who can run `docker` can mount the host filesystem into a container. That is the
accepted trade for not typing sudo in front of every container command, and it is the reason this
server has exactly one human account on it.

## 9. Caddy

From Caddy's own apt repository, so `apt-get upgrade` keeps it patched with everything else.

```bash
sudo apt-get install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list >/dev/null
sudo apt-get update
sudo apt-get install -y caddy
```

```bash
caddy version
sudo systemctl is-enabled caddy
sudo systemctl is-active caddy
curl -sSI http://127.0.0.1 | head -1
```

Assert: a version prints, the service is `enabled` and `active`, and the last line contains
`200`, which is Caddy's stock page answering on port 80. Record the version for block 12.

Two facts to state to the user, not to schedule: Caddy requests a certificate the first time a
hostname reaches it and renews on its own, so there is no cron job to add; and port 80 stays open
because that is where the certificate challenge arrives.

Leave /etc/caddy/Caddyfile as installed. Every install prompt on this site appends its own site
block and reloads.

## 10. What usually goes wrong

Three failures account for most of them. The lockout in block 6, which is why block 5 is a hard
stop. `docker` refusing to run without sudo in the same session that added the group, which is
not a broken install and needs nothing but a new connection. And a provider that has not finished
verifying the account: the server appears in the panel, `ssh vps` times out, and nothing in this
prompt is wrong. Check the provider's console before debugging SSH.

## 11. Out of scope

- Do not install fail2ban, an intrusion detector, or any other add-on. Key-only SSH behind a
  default-deny firewall is the baseline every install prompt on this site assumes, and a second
  moving part here is one nobody verified.
- Do not move SSH to a non-standard port.
- Do not create a DNS record, a Caddy site block, or a TLS certificate. The first install prompt
  does that, with a real hostname.
- Do not install an application, a database, or a language runtime. This prompt produces a
  hardened empty server and stops.
- Do not open another firewall port.

## 12. The closing checklist

Print exactly this, filled in from what the run measured, and nothing after it:

```
login user       <USER> · in the sudo group · sudo without a password · no password set
root ssh login   disabled
password ssh     disabled
firewall         default deny inbound, allow outbound · open: 22, 80, 443
auto updates     unattended-upgrades enabled · automatic reboot off
docker           server <version> · compose <version> · <USER> in the docker group
caddy            <version> · systemd enabled and active · stock page on :80
reboot pending   yes or no, from /var/run/reboot-required
your way in      ssh vps
```

Then tell the user two things and stop. Their SSH key is the only credential to this server. And
the next prompt they paste is an install prompt from a project page, which assumes every line of
that checklist is true.