Commit Graph
4 Commits
Author SHA1 Message Date
florian.wildeandClaude Opus 5.5 f66d87ad11 feat(ausrollen): Public Keys mit Trockenlauf und Backup ausrollen (#016)
Zuweisungen von Public Keys an Hosts oder Hostgruppen, ein Trockenlauf
mit Diff je Ziel und das Ausrollen genau dieses Plans. Hat sich die
Datei oder das Soll seit dem Trockenlauf geaendert, bricht das Ziel
ab: es wird nie etwas anderes geschrieben, als jemand gesehen hat.

Auf dem Host geschieht alles als Zielbenutzer, mit Sicherung, Temp-
Datei, mv und 0700/0600; der Hash wird dort erneut geprueft. Der
Deployment-Key gehoert immer zum Soll des Anmeldebenutzers.

Integrationstests gegen echtes sshd, die Oberflaechenbausteine folgen
mit der Schluesselseite aus #012.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 10:17:35 +02:00
florian.wildeandClaude Opus 5.5 17879f4c80 feat(bootstrap): Deployment-Key per Einmal-Passwort oder Befehl (#010)
Ein einziges POSIX-Skript fuer beide Wege: der Worker fuehrt es nach
einer einmaligen Passwortanmeldung aus, und genau dasselbe Skript
steht als Befehl zum Kopieren bereit. So gibt es keine zwei Wahrheiten
darueber, was ein Bootstrap auf dem Host aendert.

Das Passwort reist nur verschluesselt im Job und steht nie in Vorgang,
Protokoll oder Log. Dateien im Home des Zielbenutzers liest und
schreibt das Skript als dieser Benutzer: ein Symlink auf /etc/shadow
fuehrt zum Abbruch statt zur Kopie (Integrationstest). sudoers wird
erst nach visudo -c aktiv. Am Ende beweist eine Anmeldung per
Deployment-Key, dass sshkv ohne Passwort weiterarbeiten kann.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 09:42:45 +02:00
florian.wildeandClaude Opus 5.5 353b751df2 feat(ssh): strikte Host-Key-Pruefung und TOFU im Worker (#009)
Jede Verbindung prueft den Host-Key gegen die vertrauten Keys des
Hosts und bietet nur deren Algorithmen an - sonst koennte der Server
einen Key eines anderen Typs zeigen, den nie jemand gesehen hat. Ein
abweichender Key bricht vor dem Senden von Zugangsdaten ab, wird als
ausstehend festgehalten und oeffnet eine Abweichung.

Abrufen bricht die Verbindung im hostVerifier ab: der Mensch
entscheidet, nie der Code. Einen vertrauten Key zu ersetzen verlangt
ein ausdrueckliches ersetzen und eine frische Bestaetigung.

Integrationstest gegen ein echtes sshd inklusive Host-Key-Wechsel.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 09:37:09 +02:00
florian.wildeandClaude Opus 5.5 e89112a761 test: SSH-Testziele und Mock-OIDC fuer Integrationstests (#011)
Bootstrap, Host-Key-Pruefung und spaeteres Ausrollen brauchen echte
sshd-Gegenstellen. Zwei Debian-13-Container (ziel-a, ziel-b) in einem
gemeinsamen Netz bilden frische Hosts vor dem Bootstrap nach: root- und
Passwort-Login sind absichtlich offen, Host-Keys entstehen erst beim
Start, und `hostkeys-tauschen` erlaubt den Test "geaenderter Host-Key
wird abgelehnt" ohne Neuerstellen des Containers.

Die Testhilfen lesen dieselben Adress-Variablen wie die Compose-Datei
und lassen Tests mit Hinweis auf den Startbefehl fehlschlagen, statt
sie still zu ueberspringen - ein uebersprungener Integrationstest sieht
sonst wie ein bestandener aus.

Der Mock-OIDC-Anbieter ersetzt authentik in der Entwicklung (PLAN.md,
Entscheidung 7). Bei interaktivem Login uebernimmt er nur Claims aus dem
Formular, daher belegt eine eigene Login-Seite email, name und groups
vor und laesst die Gruppen frei waehlen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 09:13:56 +02:00