Restore drill doctor fails on rootless authorized_keys check (built-in SSH server, no authorized_keys file) #224

Stängd
öppnade 2026-07-27 09:14:51 +00:00 av supernaut · 0 kommentarer
Ägare

Symptom

BackupDrillFailed persists after #220 (lock) and #223 (app.ini path) are applied. The drill now completes the restic restore + writes the app.ini + boots forgejo doctor, which runs the full default suite — but check [4] fails:

[4] Check if OpenSSH authorized_keys file is up-to-date
 - [E] authorized_keys file "/var/lib/gitea/git/.ssh/authorized_keys" is missing
[restore] ERROR: forgejo doctor reported [E] check failures — restore is not sound

forgejo doctor itself exits 0; the drill's strict [E]-grep (restore-on-scratch.sh) treats the [E] as a failure.

Root cause — false positive for the ADR-0031 built-in SSH server

The doctor's authorized-keys check verifies the host OpenSSH authorized_keys file against the DB — a concept from the rootful host-OpenSSH-delegation model (ADR 0006). Since the ADR-0031 rootless cutover (#91), git-SSH is served by Forgejo's built-in server, which authenticates from the DB, not an authorized_keys file (the migration stashed the old OpenSSH git/ dir into .rootful-legacy/). So the file is correctly absent, and the restored SSH keys live in the DB — which the drill already verifies ("restored user rows: 10").

Prod's app.ini sets START_SSH_SERVER = true, but the drill's minimal scratch app.ini sets no SSH options, so doctor runs the check with the rootful assumption.

Fix

Set SSH_CREATE_AUTHORIZED_KEYS_FILE = false (built-in-server model) in the drill's scratch app.ini [server] block, so doctor's authorized-keys check skips. SSH-key restore soundness is already covered by the DB restore.

Third rootless follow-up for the drill (after #219/#220 lock, #222/#223 app.ini). The other 4 doctor checks (paths, DB version, user types, repo HEADs) all pass — this should complete the drill and clear the alert.

Refs #91 (ADR 0031).

## Symptom `BackupDrillFailed` persists after #220 (lock) and #223 (app.ini path) are applied. The drill now completes the restic restore + writes the app.ini + boots `forgejo doctor`, which runs the full default suite — but check [4] fails: ``` [4] Check if OpenSSH authorized_keys file is up-to-date - [E] authorized_keys file "/var/lib/gitea/git/.ssh/authorized_keys" is missing [restore] ERROR: forgejo doctor reported [E] check failures — restore is not sound ``` `forgejo doctor` itself exits 0; the drill's strict `[E]`-grep (`restore-on-scratch.sh`) treats the `[E]` as a failure. ## Root cause — false positive for the ADR-0031 built-in SSH server The doctor's `authorized-keys` check verifies the host OpenSSH `authorized_keys` file against the DB — a concept from the rootful host-OpenSSH-delegation model (ADR 0006). Since the ADR-0031 rootless cutover (#91), git-SSH is served by Forgejo's **built-in server**, which authenticates from the **DB**, not an `authorized_keys` file (the migration stashed the old OpenSSH `git/` dir into `.rootful-legacy/`). So the file is *correctly absent*, and the restored SSH keys live in the DB — which the drill already verifies ("restored user rows: 10"). Prod's app.ini sets `START_SSH_SERVER = true`, but the drill's minimal scratch app.ini sets no SSH options, so doctor runs the check with the rootful assumption. ## Fix Set `SSH_CREATE_AUTHORIZED_KEYS_FILE = false` (built-in-server model) in the drill's scratch app.ini `[server]` block, so doctor's authorized-keys check skips. SSH-key restore soundness is already covered by the DB restore. Third rootless follow-up for the drill (after #219/#220 lock, #222/#223 app.ini). The other 4 doctor checks (paths, DB version, user types, repo HEADs) all pass — this should complete the drill and clear the alert. Refs #91 (ADR 0031).
Logga in för att delta i denna konversation.
Ingen milstolpe
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens
bitborg/bitborg-infra#224
Ingen beskrivning angiven.