From 3da19421d07bd5e70b73dae5f35c6cd52f89ff30 Mon Sep 17 00:00:00 2001 From: Micha Date: Mon, 1 Jun 2026 15:09:37 +0200 Subject: [PATCH] Document hetzner account hygiene --- docs/AI_CONTEXT.md | 3 ++- docs/AUDIT_2026-05-25_TODO.md | 5 +++-- docs/EXTERNAL_DEPENDENCIES.md | 7 ++++--- docs/EXTERNAL_OPERATOR_RUNBOOK.md | 21 +++++++++++++++------ 4 files changed, 24 insertions(+), 12 deletions(-) diff --git a/docs/AI_CONTEXT.md b/docs/AI_CONTEXT.md index e6405bb..0778c93 100644 --- a/docs/AI_CONTEXT.md +++ b/docs/AI_CONTEXT.md @@ -48,7 +48,7 @@ Authoritativ: `docs/AUDIT_2026-05-25_TODO.md`. Kurzfassung: - Alt-Volumes fruehestens ab 2026-06-02 freigeben -- Hetzner-Account-Hygiene und Borg `append-only` mit `docs/EXTERNAL_OPERATOR_RUNBOOK.md` im Account/Storage-Box-SSH-Setup bestaetigen +- Borg `append-only` fuer Hetzner final klaeren; nicht erneut direkt auf produktiver `authorized_keys` testen - Auth-/OIDC-/CrowdSec-/Hermes-Themen bewusst geparkt Letzte Bestaetigung: @@ -60,3 +60,4 @@ Letzte Bestaetigung: - Externer Betreibercheck: `ops/maintenance/check-external-operator.sh`; FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`, DNS fuer Public Apps hat keine AAAA-Records, Host hat keine globale Provider-IPv6. - FRITZ!Box-UI 2026-06-01: Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, WAN-Freigabe nur `443/tcp`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus. - FRITZ!Box-Konfig-Backup 2026-06-01 extern/off-system in Vaultwarden abgelegt; Datei und Kennwort bleiben ausserhalb des Repos. +- Hetzner-Account-Hygiene 2026-06-01 erledigt: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok; Storage Box SSH-only, Maintenance-Key in Vaultwarden. Append-only forced-command brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Borg-Repo-Zugriff danach wieder geprueft. diff --git a/docs/AUDIT_2026-05-25_TODO.md b/docs/AUDIT_2026-05-25_TODO.md index 0f06799..881caa3 100644 --- a/docs/AUDIT_2026-05-25_TODO.md +++ b/docs/AUDIT_2026-05-25_TODO.md @@ -8,8 +8,7 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi | Prioritaet | Punkt | Naechster Schritt | |---|---|---| | P0 | Alt-Volumes nach Burn-in freigeben | Ab 2026-06-02 `ops/maintenance/release-alt-volumes.sh --dry-run` pruefen, danach nur bei sauberem Ergebnis mit `--execute` freigeben | -| P1 | Hetzner-Account-Hygiene | Mit `docs/EXTERNAL_OPERATOR_RUNBOOK.md` im Hetzner-Konto bestaetigen; keine Secret-Werte ins Repo | -| P1 | Borg `--append-only` fuer Hetzner pruefen | Produktiven Borg-UI-SSH-Key in der Storage-Box-`authorized_keys` per forced command auf `borg serve --append-only` einschraenken; separaten Maintenance-Key offline halten | +| P1 | Borg `--append-only` fuer Hetzner final klaeren | Nicht erneut direkt auf produktiver `authorized_keys` testen; forced-command-Versuch am 2026-06-01 brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt. Naechster Schritt: Hetzner-Support oder temporaren Sub-Account/Scratch-Repo fuer exakt getestete Syntax nutzen. | | P2 | Family-Onboarding praktisch starten | Familienkonten, Vaultwarden-Organisation und Immich-Mobile-Backup gemeinsam einrichten | ## Bewusst geparkt @@ -29,6 +28,8 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi - Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; Live-Baseline am 2026-06-01: FRITZ!OS `154.08.25`, keine Public-AAAA-Records fuer `*.kaleschke.info`, Host ohne globale Provider-IPv6, WAN `443/tcp` offen und `80/tcp`/`222/tcp` geschlossen. - FRITZ!Box-Servicefenster UI-seitig abgeschlossen: FRITZ!Box-Dienste aus dem Internet sind aus (HTTPS auf FRITZ!Box-UI, FTP/FTPS auf Speichermedien), aktive WAN-Freigabe bleibt nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus. - FRITZ!Box-Konfig-Backup exportiert und extern/off-system in Vaultwarden abgelegt: `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export`; Kennwort und Datei bleiben ausserhalb des Repos. +- Hetzner-Account-Hygiene erledigt: externe Kontakt-/Rechnungs-Mail bestaetigt, Zahlung ok, 2FA mit Google Authenticator aktiv, Recovery Key offline ausgedruckt. +- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery. - Family-View Dashboard ist repo-seitig gebaut: `monitoring/grafana/dashboards/family-status.json` zeigt Family-App-Uptime, Backup-Alter, TLS-Restlaufzeit, Critical-Container und Image-Drift. - Alt-Volume-Freigabe ist vorbereitet: `ops/maintenance/release-alt-volumes.sh --dry-run` validiert aktive Pfade, Container-Health, Restore-Freshness und gemountete Altpfade; Test am 2026-06-01 fand vier Kandidaten und keine Blocker, Ausfuehrung bleibt wegen Cutoff bis 2026-06-02 gesperrt. - Borg-Nachlauf nach dem 2026-05-31-Sprint ist belegt: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, 101669 Dateien, `rc=0`; Freshness-Check am 2026-06-01: Critical 0, Warnings 0. diff --git a/docs/EXTERNAL_DEPENDENCIES.md b/docs/EXTERNAL_DEPENDENCIES.md index 88b0518..3a91150 100644 --- a/docs/EXTERNAL_DEPENDENCIES.md +++ b/docs/EXTERNAL_DEPENDENCIES.md @@ -1,6 +1,6 @@ # External Dependencies - KalliLab CORE -Status: Betreiber-Baseline 2026-06-01; konkrete Account-Recovery-Codes und Besitznachweise muessen ausserhalb des Repos bestaetigt werden. +Status: Betreiber-Baseline 2026-06-01; Account-Recovery, Schluessel und Besitznachweise bleiben ausserhalb des Repos. ## Zweck @@ -14,7 +14,7 @@ Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recov | FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig-Backup vom 2026-06-01 liegt extern/off-system in Vaultwarden; Reset-Pin und Account-Pfad bereithalten; Remote-HTTPS/FTP/FTPS aus dem Internet sind aus | | Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern | | Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen | -| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Account-Hygiene und Borg `--append-only` als Haertung pruefen | +| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `--append-only` bleibt wegen Storage-Box-forced-command-Problem offen | | GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` | mittel/hoch | Gitea-Verlust abfederbar, Repo-Bootstrap bleibt moeglich | GitHub-Konto; PAT liegt in Gitea-Mirror-Settings, nicht im Repo | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten | | Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern | | GMX SMTP | Authelia Notifier | mittel | Mail-Notifier faellt aus, Login selbst nicht zwingend | GMX-Konto; SMTP-Secret liegt hostseitig | ntfy/zweiter SMTP als Fallback pruefen | @@ -35,7 +35,7 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng | Tailscale Account Recovery | Tailnet-Zugang | Account-2FA/Recovery Codes sichern | | SMTP Passwort | Authelia Mail | In Host-Secret, Fallback pruefen | | Domain-Registrar Recovery | Domain-Besitz und Zahlung | Account, 2FA und Zahlungsweg ausserhalb des Homelabs sichern | -| Hetzner Storage Box Zugang | Off-site Backup-Ziel | SSH-/Web-Zugang und Zahlungsweg extern sichern | +| Hetzner Storage Box Zugang | Off-site Backup-Ziel | Account 2FA aktiv, Recovery Key offline gedruckt, Zahlungsweg ok; Maintenance-Key und Storage-Box-Passwort in Vaultwarden | ## Ausfall-Szenarien @@ -80,3 +80,4 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng | 2026-05-28 | FRITZ!Box-Portfreigaben bereinigt: aktiv bleibt nur `443/tcp`; `80/tcp` entfernt, `222/tcp` bewusst nicht angelegt; UPnP-Recht fuer VONETS-Bridge deaktiviert | IPv6-/Dienste-Review am 2026-06-01 nachgezogen | | 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Hetzner Account-Hygiene und Borg append-only im Konto/Storage-Box-SSH-Key-Setup bestaetigen | | 2026-06-01 | FRITZ!Box-UI gegengeprueft und Konfig-Backup extern/off-system in Vaultwarden abgelegt; Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus | Bei naechstem Router-Update erneut exportieren | +| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. | Borg `--append-only` nur noch ueber Hetzner-Support oder Scratch/Sub-Account erneut testen | diff --git a/docs/EXTERNAL_OPERATOR_RUNBOOK.md b/docs/EXTERNAL_OPERATOR_RUNBOOK.md index ad7b12a..fac0c8f 100644 --- a/docs/EXTERNAL_OPERATOR_RUNBOOK.md +++ b/docs/EXTERNAL_OPERATOR_RUNBOOK.md @@ -24,6 +24,8 @@ Erwarteter Stand vom 2026-06-01: - FRITZ!Box-UI-Gegencheck vom 2026-06-01: Remote-HTTPS auf die FRITZ!Box ist aus, FTP/FTPS auf Speichermedien ist aus, nur `443/tcp -> 192.168.178.58` ist als WAN-Freigabe sichtbar, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus. - FRITZ!Box-Konfig-Backup vom 2026-06-01 ist extern/off-system in Vaultwarden abgelegt; Datei und Kennwort nicht ins Repo schreiben. - Borg UI nutzt `borg 1.4.x`; Repository `appdata-critical` liegt auf Hetzner Storage Box `ssh://...your-storagebox.de:23/./hetzner_borg_appdata_critical`. +- Hetzner-Account-Hygiene vom 2026-06-01: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok. +- Storage Box vom 2026-06-01: SSH aktiv, SMB/WebDAV aus, separater Maintenance-Key in Vaultwarden, produktiver Borg-UI-Key und Maintenance-Key nach Passwort-Recovery getestet. - Restore-Freshness: `Critical 0`, `Warnings 0`. ## 2. Hetzner Account-Hygiene @@ -33,7 +35,7 @@ Im Hetzner-/Storage-Box-Konto pruefen und extern/off-system dokumentieren: | Punkt | Soll | |---|---| | Passwort | stark, eindeutig, im Passwortmanager | -| 2FA | aktiv, Recovery-Codes offline auffindbar | +| 2FA | aktiv, Recovery Key offline auffindbar | | Kontakt-E-Mail | aktuell und ohne Homelab-Abhaengigkeit erreichbar | | Zahlungsweg | gueltig, Fallback bekannt | | Storage Box | Produkt, Benutzer und Rechnungsstatus sichtbar | @@ -53,22 +55,29 @@ Hetzner bestaetigt auch, dass append-only moeglich ist. Borg selbst setzt append-only pro SSH-Key typischerweise ueber einen forced command in `authorized_keys` um. -Empfohlenes Zielmodell: +Zielmodell, aber **nicht ungeprueft auf der produktiven Storage Box anwenden**: ```text -command="borg serve --append-only --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 borg-ui-append-only -command="borg serve --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 borg-maintenance +command="borg-1.4 serve --append-only --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 borg-ui-append-only +ssh-ed25519 borg-maintenance ``` Hinweise: +- Stand 2026-06-01: Ein forced-command-Versuch auf der produktiven + Storage-Box-`authorized_keys` brach die Key-Authentifizierung. Recovery + erfolgte per Storage-Box-Passwort und Upload einer bereinigten + `authorized_keys` mit Borg-UI-Key und Maintenance-Key. Daher Append-only erst + nach Hetzner-Support-Klaerung oder in einem temporaren Sub-Account/Scratch-Repo + erneut testen. - Pfad auf der Storage Box vor dem Eintragen pruefen. Bei Hetzner werden Pfade im Borg-Repo haeufig relativ als `./repo-name` verwendet; in `authorized_keys` muss der serverseitige Pfad zur Storage-Box-Home-Struktur passen. -- Der produktive Borg-UI-Key sollte append-only sein. +- Der produktive Borg-UI-Key sollte langfristig append-only sein, ist aktuell + aber bewusst wieder uneingeschraenkt, damit die produktiven Backups laufen. - Ein separater Maintenance-Key bleibt fuer bewusste Retention/Prune/Compact - noetig und darf nicht auf dem produktiven Homelab-Host liegen. + noetig und liegt in Vaultwarden; lokale temporare Key-Dateien wurden geloescht. - Append-only verhindert nicht, dass ein kompromittierter Client Archive als geloescht markiert; es verhindert die unmittelbare physische Entfernung. Nach einem Vorfall keine unbeschraenkte Schreiboperation ausfuehren, bevor