gib/Panama
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix: Complete SSH bootstrap hardening

Browse Source
This commit is contained in:
Gabriel Brown
2026-08-27 05:19:58 -04:00
parent 98e29eb8f3
commit fc8f226747
9 changed files with 852 additions and 186 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+17 -8
View File
@@ -45,15 +45,24 @@ That command also works from a brand-new VPS's **root** login. It creates or
reuses your sudo-enabled user, then copies a safe root key when it can or
verifies the target key before offering SSH hardening. A verified target key
means the target user owns `.ssh` with mode `0700` and `authorized_keys` with
mode `0600`. SSH hardening is unavailable without a verified target key, and
the install continues without it.
mode `0600`. Every non-comment line in `authorized_keys` must be valid OpenSSH
key material that `ssh-keygen` can parse. Root-key destination writes run as
the target user, and Panama rechecks the resulting owner, modes, and keys. SSH
hardening is unavailable without a verified target key or installed SSH unit,
and the install continues without it. Declining hardening also leaves SSH
unchanged.
When you accept hardening, Panama makes an atomic same-directory drop-in,
validates the complete SSH configuration with `sshd -t`, then reloads the
detected SSH unit. If validation or reload fails, it restores the previous
drop-in and validates and reloads that restored configuration; recovery that
cannot complete stops the handoff and prints the manual recovery command. The
fixture contracts exercise these branches. No real daemon reload runs under
When you accept hardening, Panama uses an atomic same-directory drop-in named
`00-panama.conf`, whose early filename gives it safer precedence. A pre-existing
symlink or non-regular object makes hardening unavailable. The effective policy
is exactly `PermitRootLogin no`, `PasswordAuthentication no`, and
`KbdInteractiveAuthentication no`. Panama validates syntax with `sshd -t` and
checks `sshd -T -C` for both root and target-user contexts before it reloads
the detected SSH unit. If validation or reload fails, it restores the previous
drop-in regular file with its metadata and validates and reloads that restored
configuration. Recovery that cannot complete stops the handoff and prints the
right manual command for either a prior file or no prior file. The fixture
contracts test these branches. No real daemon reload runs under
`panama test --safe`, so that suite is not live-host proof.
After that, it hands off to a normal install as the new user.