Ein Skript für beide Wege (Passwort im Worker, Befehl zum Kopieren) – keine zwei Wahrheiten über Änderungen am Host.
Passwort: reist verschlüsselt (SSHKV_APP_SECRET) nur im Job, Job wird nach dem Lauf gelöscht; Test: Passwort steht in keiner Tabelle. JS-Strings lassen sich nicht überschreiben – das Passwort lebt bis zur Speicherbereinigung im Worker-Speicher.
Nicht-root mit sudo-Passwort wird unterstützt (sudo -S).
Symlink-Schutz: Dateien im Home des Zielbenutzers liest und schreibt das Skript als dieser Benutzer (runuser). Test mit Symlink auf /etc/shadow: Abbruch, /etc/shadow unverändert.
CRLF: Das Bootstrap-Skript entfernt \r aus authorized_keys. Die bytegenaue Erhaltung fremder Zeilen leistet erst der TS-Merge aus #015.
Quelle: docs/issues/010-bootstrap.md – dort wird dieses Issue gepflegt.
## Ziel
Deployment-Key auf neuen Host bringen: einmalige Passwortanmeldung (nie gespeichert) oder Copy-Paste-Befehl. Dienstbenutzer `sshkv` + sudoers.
## Aufgaben
- [x] Einmal-Passwort nur im Arbeitsspeicher des Workers, verschlüsselt im Job, danach gelöscht
- [x] Bootstrap-Skript: Benutzer `sshkv`, `/etc/sudoers.d/sshkv` (geprüft mit `visudo -c`), Deployment-Key in verwaltetem Block
- [x] Alternative: Befehl zum Kopieren
- [x] Prüfung nach Bootstrap: Anmeldung per Schlüssel, sudo ohne Passwort
- [x] sshd-Check: `PermitRootLogin`, `PasswordAuthentication` (nur Anzeige)
## Akzeptanzkriterien
- [x] Integrationstest gegen Test-Container: Bootstrap per Passwort und per Befehl
- [x] Passwort taucht nirgends in DB, Logs oder Protokoll auf
## Abhängigkeiten
#009
## Notizen / Entscheidungen
- **Ein Skript für beide Wege** (Passwort im Worker, Befehl zum Kopieren) – keine zwei Wahrheiten über Änderungen am Host.
- **Passwort:** reist verschlüsselt (`SSHKV_APP_SECRET`) nur im Job, Job wird nach dem Lauf gelöscht; Test: Passwort steht in keiner Tabelle. JS-Strings lassen sich nicht überschreiben – das Passwort lebt bis zur Speicherbereinigung im Worker-Speicher.
- **Nicht-root mit sudo-Passwort** wird unterstützt (`sudo -S`).
- **Symlink-Schutz:** Dateien im Home des Zielbenutzers liest und schreibt das Skript als dieser Benutzer (`runuser`). Test mit Symlink auf `/etc/shadow`: Abbruch, `/etc/shadow` unverändert.
- **CRLF:** Das Bootstrap-Skript entfernt `\r` aus authorized_keys. Die bytegenaue Erhaltung fremder Zeilen leistet erst der TS-Merge aus #015.
- **sshd-Hinweise** (nur Anzeige): `PermitRootLogin yes` → Empfehlung `prohibit-password`; abweichendes `AuthorizedKeysFile` → Warnung.
---
Quelle: `docs/issues/010-bootstrap.md` – dort wird dieses Issue gepflegt.
florian.wilde
added this to the v0.1.0 milestone 2026-10-12 15:12:37 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ziel
Deployment-Key auf neuen Host bringen: einmalige Passwortanmeldung (nie gespeichert) oder Copy-Paste-Befehl. Dienstbenutzer
sshkv+ sudoers.Aufgaben
sshkv,/etc/sudoers.d/sshkv(geprüft mitvisudo -c), Deployment-Key in verwaltetem BlockPermitRootLogin,PasswordAuthentication(nur Anzeige)Akzeptanzkriterien
Abhängigkeiten
#009
Notizen / Entscheidungen
SSHKV_APP_SECRET) nur im Job, Job wird nach dem Lauf gelöscht; Test: Passwort steht in keiner Tabelle. JS-Strings lassen sich nicht überschreiben – das Passwort lebt bis zur Speicherbereinigung im Worker-Speicher.sudo -S).runuser). Test mit Symlink auf/etc/shadow: Abbruch,/etc/shadowunverändert.\raus authorized_keys. Die bytegenaue Erhaltung fremder Zeilen leistet erst der TS-Merge aus #015.PermitRootLogin yes→ Empfehlungprohibit-password; abweichendesAuthorizedKeysFile→ Warnung.Quelle:
docs/issues/010-bootstrap.md– dort wird dieses Issue gepflegt.