florian.wildeandClaude Opus 5.5
dc202594d3
Die automatischen Tests laufen gegen Mock-OIDC und Testcontainer. Echter authentik, echte Hosts und der Betrieb brauchen eine eigene, abhakbare Prüfung mit erwartetem Ergebnis je Punkt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
131 lines
7.4 KiB
Markdown
131 lines
7.4 KiB
Markdown
# Abnahme vor Version 1.0.0
|
||
|
||
Was die automatischen Tests **nicht** abdecken können: der echte Anbieter (authentik), echte Hosts
|
||
und der Betrieb auf dem Zielserver. Diese Liste geht genau das durch. Jeder Punkt nennt das
|
||
erwartete Ergebnis; was abweicht, kommt als Issue in `docs/issues/` (oder direkt als Notiz hier
|
||
darunter).
|
||
|
||
Voraussetzung: Installation nach [installation.md](installation.md) ist durch, `docker compose ps`
|
||
zeigt `db`, `web` und `worker` als *healthy*.
|
||
|
||
**Abnahme durch:** ____________________ **Datum:** __________ **Version/Commit:** __________
|
||
|
||
---
|
||
|
||
## A · Installation und Grundschutz
|
||
|
||
- [ ] `https://<sshkv>/api/gesundheit` antwortet mit `{"status":"ok","version":…}`; über `http://` gibt es keine Anmeldung
|
||
(Secure-Cookie).
|
||
- [ ] Von außerhalb des internen Netzes ist die Oberfläche **nicht** erreichbar (Reverse Proxy /
|
||
Firewall liefert 403 oder Timeout).
|
||
- [ ] Der Web-Container sieht den Master-Key nicht:
|
||
`docker compose exec web ls /run/secrets` → leer bzw. Fehler.
|
||
- [ ] Worker-Log beim Start: Master-Key passt, Deployment-Key vorhanden
|
||
(`docker compose logs worker | head`).
|
||
- [ ] Antwort-Header prüfen (`curl -sI https://<sshkv>/anmelden`): `Content-Security-Policy`,
|
||
`Strict-Transport-Security`, `X-Frame-Options`/`frame-ancestors`, `Referrer-Policy`.
|
||
|
||
## B · Anmeldung mit authentik
|
||
|
||
- [ ] Anmelden mit einem Konto in `sshkv-admins` → Rolle **Admin** (unten links in der Navigation).
|
||
- [ ] Konto in `sshkv-operators` → **Operator**; Konto in `sshkv-readers` → **Leser**.
|
||
- [ ] Konto in **keiner** dieser Gruppen → kein Zugang, verständliche Meldung, Eintrag
|
||
`anmeldung.verweigert` im Audit-Log.
|
||
- [ ] Gruppe in authentik entziehen → bei der nächsten Anfrage gilt die neue Rolle bzw. kein
|
||
Zugang (die Rolle kommt aus der Datenbank, nicht aus dem alten Token – spätestens nach
|
||
erneuter Anmeldung).
|
||
- [ ] **Erneute Bestätigung:** als Admin „Private Key anzeigen“ wählen → authentik fragt das
|
||
Passwort (und ggf. MFA) **wirklich neu** ab; danach geht die Aktion fünf Minuten lang ohne
|
||
erneute Frage. *Kritischer Punkt:* Kommt authentik ohne neue Eingabe zurück, meldet sshkv
|
||
„auth_time fehlt oder ist zu alt“ – dann die Flow-Einstellung in authentik prüfen.
|
||
- [ ] Abmelden beendet die Sitzung (Zurück-Knopf zeigt keine Daten mehr).
|
||
|
||
## C · Notfall-Admin
|
||
|
||
- [ ] `/anmelden` → „Notfallzugang“: Benutzer `notfall` + Passwort aus `.env` → TOTP-Einrichtung
|
||
erzwungen (QR-Code mit Authenticator-App scannen).
|
||
- [ ] Erneute Anmeldung verlangt Passwort **und** TOTP-Code; falscher Code wird abgelehnt.
|
||
- [ ] Nach fünf Fehlversuchen in 15 Minuten → „Zu viele Fehlversuche“, auch mit richtigem Passwort.
|
||
- [ ] `SSHKV_BREAKGLASS_PASSWORD` danach aus der `.env` entfernen (der Hash steht in der
|
||
Datenbank) und das Passwort im Passwortmanager ablegen.
|
||
|
||
## D · Echte Hosts aufnehmen
|
||
|
||
Mindestens zwei Hosts, möglichst unterschiedlich (z. B. Debian 12 und Ubuntu 24.04), einer mit
|
||
Anmeldeart *Dienstbenutzer*, einer mit *root*.
|
||
|
||
- [ ] Host anlegen → „Host-Key abrufen“ → Fingerprint mit dem Host vergleichen
|
||
(`ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub` **auf dem Host**) → vertrauen.
|
||
- [ ] Bootstrap per Einmal-Passwort: danach existiert `sshkv` mit `/etc/sudoers.d/sshkv`, das
|
||
Passwort steht **nirgends** (Audit-Log, `docker compose logs`, Datenbank:
|
||
`grep -r` im Dump findet es nicht).
|
||
- [ ] Bootstrap per Kopier-Befehl auf dem zweiten Host: Befehl in die Root-Shell einfügen, danach
|
||
„Einrichtung erneut prüfen“ → eingerichtet.
|
||
- [ ] „Verbindung prüfen“ → erreichbar; sshd-Befund wird angezeigt (z. B. PasswordAuthentication).
|
||
- [ ] Host-Key auf einem Host absichtlich tauschen (`ssh-keygen -A` nach Löschen der Keys,
|
||
sshd neu starten) → nächster Abgleich meldet **Host-Key geändert**, sshkv verbindet sich
|
||
nicht mehr, bis ein Admin den neuen Key bestätigt. Danach zurückdrehen.
|
||
|
||
## E · Schlüssel ausrollen (Kern-Anwendungsfall)
|
||
|
||
- [ ] Vorhandene `authorized_keys` eines Hosts mit eigenen Zeilen (Kommentare, Optionen, leere
|
||
Zeilen) vorher sichern: `cp ~/.ssh/authorized_keys /tmp/vorher`.
|
||
- [ ] Public Key eines Admins auf beide Hosts ausrollen → Dry-Run zeigt **nur** den verwalteten
|
||
Block; nach „Anwenden“ ist alles außerhalb des Blocks **byte-gleich**
|
||
(`diff` gegen `/tmp/vorher` zeigt nur den Block).
|
||
- [ ] Backup-Datei `authorized_keys.sshkv.bak.*` liegt daneben; Rechte 0600, Verzeichnis 0700.
|
||
- [ ] Host-zu-Host-Assistent: Vorlage „Deployment-Zugang“ von Host A nach Host B → Verbindungstest
|
||
grün; auf A: `ssh <alias> id -un` funktioniert ohne Rückfrage (known_hosts gesetzt).
|
||
- [ ] Datei `~/.ssh/config` auf A: eigener Inhalt außerhalb des sshkv-Blocks unverändert.
|
||
- [ ] Zielkonto anlegen (z. B. `deploy` mit sudo) → Benutzer und sudoers-Datei entstehen,
|
||
`visudo -c` auf dem Host ist sauber.
|
||
|
||
## F · Drift, Rotation, Widerruf
|
||
|
||
- [ ] Im verwalteten Block auf einem Host von Hand eine Zeile ändern → Abgleich meldet
|
||
Abweichung; Übersicht zeigt den Host; Dry-Run stellt den Soll-Stand wieder her.
|
||
- [ ] Fremden Key außerhalb des Blocks eintragen → Abgleich meldet **unbekannten Schlüssel**;
|
||
„übernehmen“ funktioniert.
|
||
- [ ] Geführte Rotation des Assistenten-Schlüssels: Alias auf A funktioniert vorher, während und
|
||
nachher; alte Datei ist weg.
|
||
- [ ] Rotation einmal **abbrechen** und danach erneut rotieren (#032, #033).
|
||
- [ ] Widerruf eines Schlüssels mit einem nicht erreichbaren Host (Host kurz stoppen) →
|
||
„Widerruf unvollständig“; nach dem Wiederanlauf abschließbar.
|
||
- [ ] **Deployment-Key rotieren** (Einstellungen → Instanz) über alle echten Hosts – danach
|
||
klappen Abgleich und Ausrollen weiter; der alte Fingerprint steht auf keinem Host mehr.
|
||
- [ ] Aussperrschutz: Den Deployment-Key auf einem Host per Hand aus dem Block löschen und
|
||
ausrollen → sshkv schreibt ihn zurück bzw. verweigert eine Änderung, die ihn entfernen würde.
|
||
|
||
## G · Audit-Log und Benachrichtigungen
|
||
|
||
- [ ] Audit-Log zeigt alle Aktionen aus D–F mit Akteur; „Kette prüfen“ → intakt.
|
||
- [ ] CSV-Export öffnet sich sauber in LibreOffice/Excel (Umlaute, Trennzeichen).
|
||
- [ ] Syslog-Kopie kommt beim Zielserver an (falls `SSHKV_SYSLOG_*` gesetzt).
|
||
- [ ] Testversand E-Mail (Microsoft 365) und Webhook aus den Einstellungen kommt an.
|
||
- [ ] Am nächsten Morgen: tägliche Zusammenfassung ist da und nennt die offenen Befunde.
|
||
|
||
## H · Sicherung und Wiederherstellung
|
||
|
||
- [ ] `sudo bash deploy/sichern.sh` läuft durch; Sicherung landet am vorgesehenen Ort.
|
||
- [ ] Master-Key **getrennt** gesichert (Passwortmanager/Tresor), Wiederauffinden geprobt.
|
||
- [ ] Wiederherstellung auf einer **Wegwerf-Instanz** nach [sicherung.md](sicherung.md): danach
|
||
Anmeldung, Private Key anzeigen und ein Abgleich funktionieren.
|
||
- [ ] Mit falschem Master-Key verweigert der Worker den Start.
|
||
|
||
## I · Oberfläche
|
||
|
||
- [ ] Smartphone (schmale Ansicht): Navigation, Übersicht, Hostliste und Dry-Run bedienbar.
|
||
- [ ] Hell/dunkel: Die App ist bewusst dunkel (Tresor-Design); Kontrast in heller Umgebung
|
||
ausreichend lesbar.
|
||
- [ ] Handbuch (`docs/anleitung/README.md`) passt zu dem, was die Oberfläche zeigt.
|
||
|
||
---
|
||
|
||
## Ergebnis
|
||
|
||
- [ ] Alle Punkte erledigt oder als Issue erfasst und als *nicht blockierend* eingestuft.
|
||
- [ ] **Freigabe für 1.0.0** – danach: Version in `package.json`, CHANGELOG-Abschnitt `[1.0.0]`,
|
||
Tag `v1.0.0`, Push.
|
||
|
||
### Notizen
|