#031 Rotation des Deployment-Keys #31

New Issue

2026-10-12T15:13:28Z

florian.wilde commented

2026-10-12 15:13:28 +00:00

Ziel

Den Deployment-Key der Instanz geführt tauschen – regelmäßig oder im Notfall (sshkv kompromittiert, siehe docs/betrieb/sicherheit.md).

Aufgaben

Neuen Deployment-Key erzeugen, ohne den alten abzulösen (zweiter Instanz-Key im Übergang)
Auf jedem eingerichteten Host den neuen Key neben den alten in den verwalteten Block des Anmeldebenutzers schreiben (Dry-Run, Ausrollen)
Verbindung mit dem neuen Key je Host prüfen
Erst wenn alle Hosts den neuen Key akzeptieren: alten aus allen Blöcken entfernen, alten Key verwerfen
Nicht erreichbare Hosts sichtbar machen; Abschluss erst, wenn alle umgestellt sind (oder bewusst übergangen)
Nur Admin mit frischer Bestätigung, alles protokolliert

Akzeptanzkriterien

Integrationstest: nach der Rotation meldet sich sshkv nur noch mit dem neuen Key an, der alte steht auf keinem Host mehr
Aussperrschutz: zu keinem Zeitpunkt steht ein Host ohne funktionierenden Deployment-Key da

Abhängigkeiten

#016, #021

Notizen / Entscheidungen

Der Nachfolger ist ein eigener Schlüssel (kategorie DEPLOYMENT, vorgaengerId = alter, noch nicht instanzStandard). sollFuer() nimmt ihn für alle Hosts mit dem Instanz-Key zusätzlich in Block und Pflichtliste – der normale Dry-Run verteilt ihn also, und der Aussperrschutz schützt beide.
Hosts mit eigenem oder Gruppen-Deployment-Key nehmen nicht teil.
Umstellen ist eine Transaktion (alter ROTIERT, neuer Standard) und verlangt eine Prüfung nach dem Erzeugen, in der jeder Host den neuen Key angenommen hat – oder bewusst übergangen wird (protokolliert).
Abschließen prüft je Host, dass der alte Fingerprint aus dem Block verschwunden ist; erst dann wird sein Private Key verworfen. Unerreichbare Hosts blockieren den Abschluss nicht (sshkv benutzt den alten Key ohnehin nicht mehr), werden aber im Ergebnis genannt.
Tests: Integrationstest gegen beide Testziele (DIENSTBENUTZER und ROOT, alte Anmeldung scheitert danach), E2E im Browser.

Quelle: docs/issues/031-deploymentkey-rotation.md – dort wird dieses Issue gepflegt.

## Ziel Den Deployment-Key der Instanz geführt tauschen – regelmäßig oder im Notfall (sshkv kompromittiert, siehe `docs/betrieb/sicherheit.md`). ## Aufgaben - [x] Neuen Deployment-Key erzeugen, ohne den alten abzulösen (zweiter Instanz-Key im Übergang) - [x] Auf jedem eingerichteten Host den neuen Key neben den alten in den verwalteten Block des Anmeldebenutzers schreiben (Dry-Run, Ausrollen) - [x] Verbindung mit dem neuen Key je Host prüfen - [x] Erst wenn alle Hosts den neuen Key akzeptieren: alten aus allen Blöcken entfernen, alten Key verwerfen - [x] Nicht erreichbare Hosts sichtbar machen; Abschluss erst, wenn alle umgestellt sind (oder bewusst übergangen) - [x] Nur Admin mit frischer Bestätigung, alles protokolliert ## Akzeptanzkriterien - [x] Integrationstest: nach der Rotation meldet sich sshkv nur noch mit dem neuen Key an, der alte steht auf keinem Host mehr - [x] Aussperrschutz: zu keinem Zeitpunkt steht ein Host ohne funktionierenden Deployment-Key da ## Abhängigkeiten #016, #021 ## Notizen / Entscheidungen - Der Nachfolger ist ein eigener Schlüssel (`kategorie DEPLOYMENT`, `vorgaengerId` = alter, noch nicht `instanzStandard`). `sollFuer()` nimmt ihn für alle Hosts mit dem Instanz-Key zusätzlich in Block **und** Pflichtliste – der normale Dry-Run verteilt ihn also, und der Aussperrschutz schützt beide. - Hosts mit eigenem oder Gruppen-Deployment-Key nehmen nicht teil. - Umstellen ist eine Transaktion (alter ROTIERT, neuer Standard) und verlangt eine Prüfung **nach** dem Erzeugen, in der jeder Host den neuen Key angenommen hat – oder bewusst übergangen wird (protokolliert). - Abschließen prüft je Host, dass der alte Fingerprint aus dem Block verschwunden ist; erst dann wird sein Private Key verworfen. Unerreichbare Hosts blockieren den Abschluss nicht (sshkv benutzt den alten Key ohnehin nicht mehr), werden aber im Ergebnis genannt. - Tests: Integrationstest gegen beide Testziele (DIENSTBENUTZER und ROOT, alte Anmeldung scheitert danach), E2E im Browser. --- Quelle: `docs/issues/031-deploymentkey-rotation.md` – dort wird dieses Issue gepflegt.

florian.wilde added this to the v1.0.0 milestone 2026-10-12 15:13:28 +00:00

florian.wilde added the sicherheit backend labels 2026-10-12 15:13:28 +00:00

florian.wilde referenced this issue from a commit

2026-10-12 15:13:30 +00:00

chore(gitea): Issues nach Gitea, Basic-Auth fuer Konto-Passwort (#030)

florian.wilde referenced this issue from a commit

2026-10-12 15:27:34 +00:00

feat(deploymentkey): geführte Rotation des Deployment-Keys (#031)

florian.wilde closed this issue

2026-10-12 16:08:17 +00:00

florian.wilde referenced this issue from a commit

2026-10-12 16:08:21 +00:00