CT-103 SSH Migration abgeschlossen und dokumentiert.

2026-09-24 17:34:33 +02:00
parent 03a284c66e
commit 0758813e63
5 changed files with 71 additions and 33 deletions
@@ -65,7 +65,7 @@ Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse
 | LLM-Serving | zwei unveränderlich definierte Modellkandidaten und technische Sollkonfiguration | Modelle, Quadlets, dauerhaftes Podman-Netz und Health Checks |
 | Deployment | lokales Ansible-Control-Projekt und idempotente Hostrollen | statische CI, Runner, geschützte Freigaben, Production-Inventar und automatisierter Rollback |
 | VPN | wg-easy v15.4.0 und Regelwerke am 22.09.2026 live geprüft; Schlüsseldateien auf `0600` gehärtet | serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme |
-| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo und SSH-Baseline aktiv; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und Wiederanlauf; Keycloak-Adminpfad weiterhin offen; Netzwerk- und Rebootabnahme der SSH-Baseline |
+| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und deren Wiederanlauf; Keycloak-Adminpfad weiterhin offen |
 | Encoding | Konto, Pfade und eigener rootless Store | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest |

 Ein Zielbild, eine Betreiberangabe oder ein erfolgreicher Teiltest gilt nicht als
@@ -4,7 +4,7 @@

 **Titel:** Priorisierte Roadmap für Ghostnet.AI

-**Stand:** 2026-09-22
+**Stand:** 2026-09-24

 **Status:** Arbeitsgrundlage; Entscheidungstore vor externer Veröffentlichung offen

@@ -61,14 +61,17 @@ Netzwerkgrenzen, bevor weitere öffentliche Dienste hinzukommen.
 - WAN- und IPv6-Exposure für Managementports erfassen;
 - Ergebnisse mit Datum und Negativtests in GNAI-006/GNAI-007 dokumentieren.

-**Ausführungsstand 22.09.2026:** Die externe Keycloak-Administration und die
+**Ausführungsstand 24.09.2026:** Die externe Keycloak-Administration und die
 fehlende VPN-Rollenisolierung sind live bestätigt. Die Schlüsseldateien des
-WireGuard-Gateways wurden auf `0600` gehärtet. Für die nächsten wirksamen
-Änderungen fehlen (1) ein aktueller Rückfallstand und administrativer Zugriff
-auf CT 103 sowie (2) die verbindliche Rolle der beiden vorhandenen VPN-Peers.
-Die technische Reihenfolge ist deshalb: Backup und Recovery-Pfad sichern,
-öffentlichen `/admin`-Pfad sperren und regressionsprüfen, Peers zuordnen und
-Gateway-Regeln umsetzen, anschließend Fail2Ban- und Wiederanlauftests.
+WireGuard-Gateways wurden auf `0600` gehärtet. Auf CT 103 sind persönlicher und
+lesender Schlüsselzugang, passwortgeschütztes sudo, SSH-Härtung,
+LAN/WireGuard-Netzbaseline und der Wiederanlauf nach einem kontrollierten
+Neustart abgenommen. Für die nächsten wirksamen Änderungen fehlen weiterhin
+(1) ein aktueller Rückfallstand vor der Keycloak-Änderung sowie (2) die
+verbindliche Rolle der beiden vorhandenen VPN-Peers. Die technische Reihenfolge
+ist deshalb: Backup sichern, öffentlichen `/admin`-Pfad sperren und
+regressionsprüfen, Peers zuordnen und Gateway-Regeln umsetzen, anschließend die
+noch offenen Fail2Ban-Funktionstests abschließen.

 **Fertig, wenn:** Die vier priorisierten Sicherheitsbefunde im zentralen Index
 als bestanden oder mit ausdrücklich akzeptiertem Restrisiko dokumentiert sind.
@@ -16,6 +16,7 @@
 | 2026-09-16 | 1.2 | spektr | Fail2Ban-Pin `1.1.0-r2-ls43` und wieder laufenden Container als Ist-Stand übernommen; technische Abnahme bleibt in GNAI-006 geführt. |
 | 2026-09-18 | 1.3 | spektr | KI-Anwendungsdienste als Zielbild und bestehende Fail2Ban-Jails als dokumentierten Ist-Stand eingeordnet. |
 | 2026-09-21 | 1.4 | spektr / Codex | Zugriffsziel von einer vorentschiedenen LiteLLM-Implementierung auf eine noch festzulegende API-Policy-Schicht verallgemeinert |
+| 2026-09-24 | 1.5 | Codex | Einfache serverseitige SSH-Netzbaseline festgelegt: TCP 22 aus lokalem LAN und über WireGuard erreichbar, öffentliche Netze gesperrt; Anmeldung weiterhin nur mit individuellen Public Keys. |

 ---

@@ -149,13 +150,21 @@ API-Keys sollen:

 ### 4.4 SSH

-SSH wird auf dem LLM-Server schlüsselbasiert betrieben.
+SSH wird auf den Servern schlüsselbasiert betrieben. Die serverseitige
+Netzbaseline erlaubt TCP 22 aus dem lokalen LAN sowie für Verkehr, der über das
+WireGuard-Gateway zum Server gelangt. Eine zusätzliche Einschränkung auf eine
+einzelne Admin-Workstation oder deren dynamische DHCP-Adresse ist nicht
+vorgesehen. Öffentliche Netze bleiben ausgeschlossen.

-Zusätzliche Schutzschicht:
+Diese grobe Netzgrenze ersetzt keine Authentifizierung: Jeder tatsächliche
+Login benötigt einen individuell zugeordneten SSH-Public-Key. Passwort- und
+Root-Login über SSH bleiben deaktiviert. Die Umgebung verwendet derzeit
+Public-Key-Authentifizierung, keine von einer SSH-CA signierten
+OpenSSH-Zertifikate.

-WireGuard-Zielberechtigung und eigener SSH-Public-Key-Login.
-
-Passwort- und Root-Login über SSH bleiben deaktiviert.
+VPN-Rollen dürfen weiterhin vorgelagert am WireGuard-Gateway steuern, welche
+Zielserver ein Peer überhaupt erreicht. Die Zielserver führen jedoch keine
+zusätzliche per-Workstation- oder per-Peer-SSH-Allowlist.

 ---

@@ -2,7 +2,7 @@

 **Dokumenten-ID:** GNAI-011-SEC  
 **Titel:** Gemeinsame SSH-Sicherheitsarchitektur der LXCs auf Ghostnet Proxmox  
-**Status:** Legacy-Root-Bestand und Zielbild definiert; CT-103-Identitäten und SSH-Baseline umgesetzt, Netzwerk-/Rebootabnahme offen  
+**Status:** Legacy-Root-Bestand und Zielbild definiert; CT-103-SSH-Rollout einschließlich Neustart abgenommen
 **Geltungsbereich:** LXCs auf Proxmox `10.0.0.2`; nicht der Proxmox-Host selbst  
 **Referenzen:** [KI-Host-SSH](../ghostnet-ai/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../GNAI-005-SEC_Access-Control.md), [CT 103](ct-103/GNAI-006-SEC_Reverse-Proxy.md), [CT 105](ct-105/GNAI-007-SEC_VPN.md)

@@ -16,6 +16,9 @@
 | 2026-09-22 | 0.4 | Codex | Persönliches Administrationskonto für CT 103 auf `ghost` festgelegt; bestehendes CT-105-Konto `admin` bleibt eine dokumentierte Ausnahme. |
 | 2026-09-22 | 0.5 | Codex | CT-103-Allowlist auf `ghost-agent ghost` korrigiert; Dienstzustand und neue Agentenverbindung erfolgreich geprüft. |
 | 2026-09-22 | 0.6 | Codex | Persönliches Konto `ghost`, passphrasegeschützten Schlüssel und passwortgeschütztes sudo auf CT 103 eingerichtet und praktisch abgenommen. |
+| 2026-09-24 | 0.7 | Codex | Effektive CT-103-INPUT-DROP-Policy und LAN-Begrenzung von SSH bestätigt; engere Management-Allowlist wegen dynamischer Workstation-Adresse zurückgestellt. |
+| 2026-09-24 | 0.8 | Codex | Einfache Host-Netzbaseline für alle Server festgelegt: SSH aus LAN und via WireGuard zulassen, keine Workstation-`/32`-Allowlist; CT 103 serverseitig abgenommen. |
+| 2026-09-24 | 1.0 | Codex | Kontrollierten CT-103-Neustart, Dienstwiederanlauf, Firewallwirkung, öffentliche Proxy-Pfade sowie Agenten- und persönlichen SSH-Zugang erfolgreich abgenommen. |

 ## 1. Zweck und Abgrenzung

@@ -41,8 +44,11 @@ Verfahren.

 Öffentliche Anwendungsports eines LXC begründen keine öffentliche
 SSH-Freigabe. SSH ist ausschließlich Managementverkehr und wird auf der
-Netzwerkebene auf vertrauenswürdiges LAN sowie berechtigte VPN-Rollen begrenzt.
-Ein LLM-Admin-Peer erhält keinen SSH-Pfad zu CT 103 oder anderen Service-LXCs.
+Netzwerkebene auf das lokale LAN sowie über das WireGuard-Gateway kommenden
+Verkehr begrenzt. Welche Zielserver ein einzelner VPN-Peer erreicht, kann
+weiterhin am Gateway gesteuert werden; der Ziel-LXC pflegt dafür keine zweite
+per-Peer- oder per-Workstation-Allowlist. Ein erreichbarer TCP-Port gewährt
+ohne zugeordneten Public Key keine Anmeldung.

 ## 3. Identitäten und Schlüssel

@@ -136,11 +142,14 @@ erfolgreich war.

 ## 5. Netzwerk- und Berechtigungsgrenze

- Der lokale LXC-Paketfilter erlaubt TCP 22 nur aus bestätigten
-  Managementquellen.
- Familie und Server Admin dürfen den SSH-Netzpfad nur gemäß GNAI-005 nutzen;
-  die Anmeldung benötigt zusätzlich einen individuellen SSH-Schlüssel.
- LLM Admin und öffentliche Netze bleiben gesperrt.
+- Der lokale LXC-Paketfilter erlaubt TCP 22 aus dem lokalen LAN und für den
+  über WireGuard weitergeleiteten beziehungsweise maskierten Verkehr.
+- Eine zusätzliche Einschränkung auf einzelne Admin-Workstations oder
+  dynamische DHCP-Adressen wird auf den Zielservern nicht gepflegt.
+- Die Anmeldung benötigt unabhängig vom Netzpfad einen individuellen
+  SSH-Public-Key; Root- und Passwort-SSH bleiben gesperrt.
+- Öffentliche Netze bleiben gesperrt. Optionale VPN-Rollentrennung wird am
+  WireGuard-Gateway vor NAT durchgesetzt, nicht erneut auf jedem Zielserver.
 - Solange WireGuard-Verkehr vor dem LAN-Ausgang maskiert wird, sieht ein LXC
  typischerweise `10.0.0.15` als Quelle. Die Rollentrennung muss deshalb bereits
  am WireGuard-Gateway vor NAT wirksam sein.
@@ -202,7 +211,9 @@ Reihenfolge:
 | Effektive Abnahme | Konsolenprüfung bestätigt `PermitRootLogin no`, `PasswordAuthentication no`, Public-Key-Pflicht, `AllowUsers ghost-agent ghost`, `MaxAuthTries 3`, `LoginGraceTime 30`, `LogLevel VERBOSE` sowie deaktivierte X11-, Agent-, TCP-Forwarding- und Tunnelfunktionen. `ssh.service` und `ssh.socket` sind aktiv; eine anschließend neu aufgebaute Verbindung als `ghost-agent` war erfolgreich. |
 | Negativtests | Neue Agentensitzung erfolgreich; Passwortversuch für `ghost-agent` und Root-Versuch mit dem Agentenschlüssel jeweils mit `Permission denied (publickey)` abgelehnt. |
 | Schlüsseldatei | Der beim Konsolen-Paste getrennte Kommentar wurde auf eine gültige `authorized_keys`-Zeile korrigiert; Fingerprint und neuer Login erneut erfolgreich geprüft. |
-| Persönlicher Zugang | `ghost` als UID/GID 1001 mit den Gruppen `sudo` und `users` eingerichtet. Der dedizierte, passphrasegeschützte Ed25519-Schlüssel hat den Fingerprint `SHA256:tIV8GMBzFcMSzaQhmkAw7wSvKDf82RHVoTKVJk7bAgA`; `.ssh` ist `0700`, `authorized_keys` `0600`. Interaktiver Login und passwortgeschütztes `sudo` bis `uid=0(root)` wurden erfolgreich geprüft. Es gilt kein `NOPASSWD`. |
+| Persönlicher Zugang | `ghost` als UID/GID 1001 mit den Gruppen `sudo` und `users` eingerichtet. Der dedizierte, passphrasegeschützte Ed25519-Schlüssel hat den Fingerprint `SHA256:tIV8GMBzFcMSzaQhmkAw7wSvKDf82RHVoTKVJk7bAgA`; `.ssh` ist `0700`, `authorized_keys` `0600`. Interaktiver Login und passwortgeschütztes `sudo` bis `uid=0(root)` wurden erfolgreich geprüft. Es gilt kein `NOPASSWD`; die temporäre Public-Key-Kopie wurde aus `/tmp` entfernt. |
+| Netzwerkfilter | Aktiver und beim Boot aktivierter nftables-Dienst mit INPUT-Policy `drop`; TCP 22 und 81 werden nur aus `10.0.0.0/24`, TCP 80 und 443 allgemein angenommen. Der SSH-Listener bindet zwar an `*:22`, wird aber durch den Paketfilter begrenzt. Die LAN-Regel schließt den durch CT 105 maskierten WireGuard-Verkehr mit Quelladresse `10.0.0.15` ein und entspricht damit der beschlossenen einfachen Host-Netzbaseline. Eine Workstation-`/32`-Allowlist ist bewusst nicht vorgesehen. |
+| Neustartabnahme | Kontrollierter Neustart am 24.09.2026; neuer Bootzeitpunkt `15:01:14`. `ssh.socket`, `ssh.service`, `nftables`, NPM und Fail2Ban waren danach aktiv, keine systemd-Unit fehlgeschlagen. Agenten- und persönlicher Schlüsselzugang sowie passwortgeschütztes sudo funktionierten. Port 81 war aus dem LAN erreichbar, Port 3000 durch die Firewall nicht erreichbar; Vaultwarden, Keycloak, Jellyfin, Nextcloud/OIDC und Gitea antworteten erfolgreich. |

 ## 8. Abnahmekriterien

@@ -212,7 +223,7 @@ Reihenfolge:
 - [x] Persönlicher Schlüsselzugang und passwortgeschütztes sudo funktionieren.
 - [x] Root- und Passwort-Login werden extern abgelehnt; Keyboard-Interactive ist in der Baseline deaktiviert.
 - [x] X11-, Agent-, TCP-Forwarding und Tunnel sind aus.
- [ ] SSH ist nur aus zugelassenen LAN-/VPN-Pfaden erreichbar.
+- [x] SSH ist serverseitig nur aus LAN und über den WireGuard-Pfad erreichbar; öffentliche Netze sind durch die aktive INPUT-DROP-Policy ausgeschlossen.
 - [x] SSH-Dienst wurde nach dem Socket-Aktivierungsereignis erfolgreich neu gestartet und erneut verbunden.
- [ ] LXC-Neustart und Wiederanlauf wurden erfolgreich geprüft.
- [ ] Private Schlüssel, Passwörter und vollständige `authorized_keys` fehlen in Git und Laufprotokollen.
+- [x] LXC-Neustart und Wiederanlauf wurden erfolgreich geprüft.
+- [x] CT-103-Private-Keys, Passwörter und Inhalte der beiden `authorized_keys` fehlen in Git und Laufprotokollen; dokumentiert sind nur Pfade und Public-Key-Fingerprints.
@@ -2,7 +2,7 @@

 **Dokumenten-ID:** GNAI-006-SEC  
 **Titel:** Reverse Proxy und Fail2Ban – Konfiguration, Betrieb und Sicherheitsabnahme  
-**Status:** NPM 2.15.1 und Fail2Ban aktiv; lesender SSH-Zugang und lokale Dateirechte gehärtet; Keycloak-Admin-Exposure offen
+**Status:** NPM 2.15.1 und Fail2Ban aktiv; SSH-Rollout und lokale Dateirechte gehärtet; Keycloak-Admin-Exposure offen

 **Vorgänger / Referenzen:** [Architektur](../../../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [WireGuard](../ct-105/GNAI-007-SEC_VPN.md)  

@@ -27,6 +27,9 @@
 | 2026-09-22 | 2.0 | Codex | Persönlichen CT-103-Zugang auf `ghost` statt des geteilten Rollenbegriffs `admin` festgelegt; Allowlist-Korrektur als offen ausgewiesen. |
 | 2026-09-22 | 2.1 | Codex | Allowlist auf `ghost-agent ghost` korrigiert; SSH-Dienste und neue Agentenverbindung erfolgreich geprüft. |
 | 2026-09-22 | 2.2 | Codex | Persönliches Konto `ghost`, dedizierten Schlüssel und passwortgeschütztes sudo eingerichtet und erfolgreich geprüft. |
+| 2026-09-24 | 2.3 | Codex | Aktive nftables-INPUT-DROP-Policy, LAN-Begrenzung von SSH und Boot-Aktivierung bestätigt; temporäre Public-Key-Datei entfernt. |
+| 2026-09-24 | 2.4 | Codex | LAN- und WireGuard-Erreichbarkeit als bewusste einfache SSH-Netzbaseline bestätigt; engere Workstation-Allowlist verworfen. |
+| 2026-09-24 | 2.5 | Codex | Kontrollierten Neustart und Wiederanlauf von SSH, nftables, NPM, Fail2Ban und öffentlichen Proxy-Pfaden erfolgreich abgenommen. |

 ---

@@ -64,10 +67,11 @@ Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentrale
 Im Ausgangszustand besaß CT 103 ausschließlich das Legacy-Konto `root`.
 Die Konsolenprüfung am 22.09.2026 zeigte für Root den Passwortstatus `NP`,
 keinen installierten Root-Schlüssel und `PermitRootLogin without-password`.
-Root kann damit derzeit nicht remote anmelden; die Proxmox-Konsole ist der
-administrative Zugang. Ein externer Handshake bestätigte TCP/22, OpenSSH `10.0p2
-Debian-7+deb13u4`, den bekannten ED25519-Hostschlüssel und die global
-angebotenen Methoden `publickey,password`. Effektiv gelten außerdem
+Root konnte damit im Ausgangszustand nicht remote anmelden; die
+Proxmox-Konsole war der administrative Zugang. Ein externer Handshake
+bestätigte damals TCP/22, OpenSSH `10.0p2 Debian-7+deb13u4`, den bekannten
+ED25519-Hostschlüssel und die global angebotenen Methoden
+`publickey,password`. Effektiv galten außerdem
 `PasswordAuthentication yes`, `KbdInteractiveAuthentication no` und
 `PubkeyAuthentication yes`. Passwörter werden weder in
 diesem Repository noch in automatisierten Laufprotokollen verarbeitet.
@@ -109,10 +113,21 @@ Hostschlüsselprüfung und ausschließlich diesen Schlüssel.
 | Updates | `unattended-upgrades` aktiv und aktiviert; apt-daily- und apt-daily-upgrade-Timer vorhanden. |
 | Containerdefinition | NPM ist im Quadlet auf `2.15.1`, Fail2Ban auf `1.1.0-r2-ls43` gepinnt. Beide laufen rootful mit Hostnetz; Fail2Ban besitzt `NET_ADMIN` und `NET_RAW`. |
 | Listener | TCP 80, 81 und 443 auf IPv4, TCP 22 und NPM-Backend 3000 auf IPv4/IPv6 beziehungsweise allen Adressen. Auf `eth0` existiert nur IPv4 plus link-lokales IPv6. Listener beweisen keine Erreichbarkeit durch die Firewall. |
-| Firewall-Datei | `/etc/nftables.conf` enthält INPUT `drop`, erlaubt 22/81 aus `10.0.0.0/24`, 80/443 allgemein und lässt Port 3000 durch die Default-Policy fallen. Der effektive Kernel-Regelsatz benötigt Root und ist noch nicht live bestätigt. |
+| Firewall | Persistente und aktive nftables-INPUT-Policy `drop`; erlaubt TCP 22/81 aus `10.0.0.0/24` und TCP 80/443 allgemein. Port 3000 fällt durch die Default-Policy. `nftables.service` ist aktiv und aktiviert. Der SSH-Socket lauscht auf `*:22`, seine Netzfreigabe wird durch nftables begrenzt. |
 | SSH | `ghost-agent` und persönliches Konto `ghost` mit getrennten Schlüsseln aktiv; Drop-in mit `AllowUsers ghost-agent ghost`. Root-/Passwortversuche extern abgelehnt, persönlicher Login und passwortgeschütztes sudo erfolgreich. `ssh.socket` und `ssh.service` aktiv. |
 | Speicher | Root-Dateisystem 51 % belegt. |

+### 2.3 Wiederanlaufabnahme am 24.09.2026
+
+Nach einem kontrollierten CT-Neustart meldete das System den neuen
+Bootzeitpunkt `15:01:14`. `ssh.socket`, `ssh.service`, `nftables`, NPM und
+Fail2Ban waren aktiv; fehlgeschlagene systemd-Units wurden nicht gemeldet.
+Sowohl `ghost-agent` als auch der persönliche Schlüsselzugang `ghost`
+funktionierten, einschließlich passwortgeschütztem sudo bis Root. Port 81 war
+aus dem LAN erreichbar, während Port 3000 in einen Timeout lief. Vaultwarden,
+Keycloak, Jellyfin, Nextcloud mit OIDC-Weiterleitung und Gitea antworteten über
+den Reverse Proxy erfolgreich.
+
 **Lokaler Berechtigungsbefund und Korrektur:** NPM lief im LXC als Root, aber
 `database.sqlite` und `keys.json` waren `0644` in einem durchsuchbaren
 `0755`-Datenverzeichnis. Das Logverzeichnis war `0777`; zahlreiche rotierte
@@ -159,7 +174,7 @@ table inet filter {
 | 80 | TCP | HTTP Ingress (NPM) | Öffentlich |
 | 443 | TCP | HTTPS Ingress (NPM) | Öffentlich |
 | 81 | TCP | NPM Web Admin Interface | Nur LAN (`10.0.0.0/24`) |
-| 22 | TCP | OpenSSH Management | Nur LAN (`10.0.0.0/24`) |
+| 22 | TCP | OpenSSH Management | LAN (`10.0.0.0/24`) einschließlich des durch CT 105 maskierten WireGuard-Verkehrs |
 | 3000 | TCP | NPM Node.js Backend | Intern / Nicht exponiert |

 `10.0.0.0/24` in den Freigaben für 22/81 umfasst auch die Gateway-Adresse `10.0.0.15`. Durch das aktuelle VPN-MASQUERADE erscheinen VPN-Clients bei NPM unter dieser Adresse. Die Port-Matrix beschreibt deshalb **keine** bereits wirksame VPN-Rollentrennung; diese muss am Gateway vor NAT umgesetzt und getestet werden.