Handoff: SSH-Hostkey-TOFU-Stand dokumentiert

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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW

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