From 5c582a006b84fd2e9da624432fa35205dfe65c8f Mon Sep 17 00:00:00 2001 From: Kay Date: Sun, 13 Sep 2026 00:41:43 +0200 Subject: [PATCH] Handoff: SSH-Hostkey-TOFU-Stand dokumentiert MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit M7 als teilweise erledigt markiert (implementiert, aber noch nicht gegen echte Hardware getestet), alte lo-Regel-Einschränkung entfernt (durch Werksreset des Testgeräts erledigt), nächste Schritte um den neuen TOFU-Dialog beim ersten Verbinden ergänzt. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW --- HANDOFF.md | 40 +++++++++++++++++++++++----------------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/HANDOFF.md b/HANDOFF.md index 5e368ed..3062256 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -64,9 +64,10 @@ RouterOSAssistant/ Networking/ RouterOSTransport.swift — Protocol: connect/fetchDeviceInfo/fetchInterfaces/fetchFirewallRuleCounts/apply/disconnect RestTransport.swift — REST-API (RouterOS ≥7.1), Zertifikats-TOFU, .set via GET+PATCH (findItemID) - SSHTransport.swift — SSH-Fallback via Citadel, CLI-Text-Parsing, resetToFactoryDefaults() + SSHTransport.swift — SSH-Fallback via Citadel, CLI-Text-Parsing, resetToFactoryDefaults(), eigene Hostkey-TOFU RouterOSCliParser.swift — parst `/system resource print` und `/interface print terse` - CertificateTrustStore.swift / CertificateFingerprint.swift — TOFU nur für REST bisher + CertificateTrustStore.swift / CertificateFingerprint.swift — TOFU für REST-Zertifikate + SSHHostKeyTrustStore.swift / SSHHostKeyFingerprint.swift — TOFU für SSH-Hostkeys (M7) Services/ ConnectionService.swift — zentraler App-State: REST-zuerst-SSH-Fallback, hält credentials/interfaces/deviceInfo BackupService.swift — Config-Export (`/export terse`) über eigene SSH-Verbindung, wählbarer Zielordner @@ -161,8 +162,6 @@ wiederholen. ## Bekannte Einschränkungen (bewusst, nicht vergessen) -- **SSH-Hostkey-TOFU fehlt** — `SSHTransport` nutzt `.acceptAnything()`, - kein Trust-on-first-use wie bei REST. M7-Punkt, im Code kommentiert. - **REST-Pfad ungetestet für Schreibvorgänge** — auf beiden bisherigen Testgeräten war `www-ssl` (Port 443) aus, jeder Schreibtest lief über SSH. Der REST-`apply()`-Pfad (`POST`/`PATCH`, `findItemID` für `.set`) @@ -177,11 +176,6 @@ wiederholen. wurde nur die Interface-**Auswahl** erneut bestätigt ("alle Interfaces auswählbar"), nicht aber ein erneuter Firewall-Apply mit korrektem Interface + Kontrolle der resultierenden Regeln. -- **Alte, fehlerhafte "lo"-Regeln stehen eventuell noch auf dem - hEX-Testgerät** — Aufräum-Befehle wurden dem Nutzer gegeben - (`/ip firewall nat remove [find out-interface=lo]`, - `/ip firewall filter remove [find in-interface=lo]`), Ausführung nicht - bestätigt. - **Neuer RouterOS-WiFi-Treiber (`/interface wifi`, wifiwave2/802.11ax) nicht unterstützt** — wird erkannt und im UI erklärt, aber nicht konfiguriert. @@ -190,6 +184,14 @@ wiederholen. - **App ist ad-hoc signiert, nicht notarisiert** — beim ersten Start einer frisch nach `/Applications` kopierten Version zeigt macOS die "nicht verifizierter Entwickler"-Warnung (Rechtsklick → Öffnen nötig). +- **SSH-Hostkey-TOFU (neu) noch nicht gegen echte Hardware getestet** — + Fingerprint-Berechnung ist per Unit-Test gegen `ssh-keygen` verifiziert, + aber der komplette Verbindungs-Flow (erste Verbindung zeigt den + "Unbekannter SSH-Schlüssel"-Dialog, Bestätigen merkt sich den + Fingerabdruck, zweite Verbindung läuft ohne Rückfrage durch) lief noch + nie gegen ein reales Gerät. **Erwartet:** nach dem Werksreset des + hEX-Testgeräts zeigt die nächste Verbindung diesen Dialog garantiert + einmalig neu (kein Bug, sondern der erste TOFU-Moment für diesen Host). ## Stand der Milestones @@ -206,18 +208,22 @@ wiederholen. wiederherstellen" (Gefahrenzone im Sicherungen-Tab, `/system reset-configuration no-defaults=no`), eigenes App-Icon ("Signal Router"-Motiv). -- ⬜ M7: Härtung — SSH-Hostkey-TOFU, Fehlerzustände, Politur, REST- - Schreibpfad gegen ein Gerät mit aktivem `www-ssl` verifizieren. +- 🔶 M7: Härtung — SSH-Hostkey-TOFU **implementiert, ungetestet gegen + echte Hardware** (siehe Einschränkungen); Fehlerzustände/Politur und + REST-Schreibpfad-Verifikation gegen ein Gerät mit aktivem `www-ssl` + stehen noch aus. ## Nächste Schritte -1. Auf dem hEX-Testgerät die alten "lo"-Firewallregeln aufräumen (siehe - oben) und den Firewall-Schritt mit jetzt korrekt erkanntem WAN-Port - erneut anwenden + Ergebnis per `/ip firewall filter print` / - `/ip firewall nat print` kontrollieren. +1. hEX-Testgerät wurde per Werksreset zurückgesetzt (räumt auch die alten + "lo"-Firewallregeln auf) — den kompletten Wizard einmal neu durchlaufen + (WAN/LAN/VLAN/WLAN/Firewall) und dabei gezielt den neuen + SSH-Hostkey-TOFU-Dialog beim ersten Verbinden bestätigen; danach + Firewall-Ergebnis mit korrektem WAN-Port per `/ip firewall filter + print` / `/ip firewall nat print` kontrollieren. 2. WLAN (M5) an einem Gerät mit echtem WLAN-Chip nachholen. -3. M7-Härtung, insbesondere SSH-Hostkey-TOFU und ein REST-Schreibtest an - einem Gerät mit aktivem `www-ssl`. +3. Rest von M7: Fehlerzustände/Politur, REST-Schreibtest an einem Gerät + mit aktivem `www-ssl`. Kein Gitea-Remote vorhanden — falls der Nutzer später eine Gitea-Instanz aufsetzt (z.B. selbst gehostet auf der vorhandenen OMV-NAS, siehe