Dedizierte SSH-Dienste (BackupService u.a.) sind der erste echte
SSH-Kontakt zu einem per REST verbundenen Router und trafen dort auf
einen unbestätigten Hostkey ohne Trust-UI (nur ReviewApplyView/
ExpertMenuDetailView-Fehlertext, kein Bestätigungsweg). Fix: nach
jedem erfolgreichen REST-Connect prüft ConnectionService den
SSH-Hostkey einmalig im Hintergrund und zeigt bei Bedarf denselben
Trust-Dialog wie der SSH-Fallback, ohne die aktive REST-Verbindung neu
aufzubauen. Live bestätigt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
M26: SavedRouter bekommt ein optionales serialNumber-Feld. Zwei
physisch verschiedene Router mit identischem Host+Benutzername
(Werks-Adresse) blieben bisher ein gemeinsamer "Bekannte Router"-
Eintrag; recordSuccessfulConnection matcht jetzt zusätzlich nach
Seriennummer, mit sauberer Migration bestehender Einträge ohne
Seriennummer. Drei neue Tests.
M27, beim Live-Test von M26 gefunden:
- Passwort-Anzeige-Button (Augen-Symbol) im Verbinden-Tab
- Bug 35: KeychainService speicherte Passwörter nur nach
"username@host" — beide Router teilten sich denselben
Schlüsselbund-Eintrag trotz getrennter SavedRouter-Einträge. Fix:
optionaler serialNumber-Parameter qualifiziert den Account-Key,
mit Fallback auf den alten Key für bereits gespeicherte Passwörter.
- Bug 36: neuer Router zeigte keine Routerboard-Infos/Seriennummer —
derselbe Root Cause wie der zuvor gemeldete "Jetzt prüfen"-Fehler:
/system routerboard und /system package update scheitern auf diesem
Router mit "expected end of command" statt dem bisher einzig
abgefangenen "bad parameter terse". SSHTransport.fetchMenuItems
erkennt jetzt beide Formulierungen.
Alles live bestätigt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
M17: "Bekannte Router" im Verbinden-Tab (SavedRouter/SavedRoutersStore),
Standort-Freitextfeld, Scroll-Cap ab 4 Einträgen. Bugfix: Umbenennen-
TextField steckte in einem sich selbst deaktivierenden Button.
M18: Live-Traffic-Punkt an Interfaces (InterfaceTrafficMonitor, eigene
SSH-Verbindung, monitor-traffic-Polling). Dabei zwei reale CLI-Parser-Bugs
gefunden und gefixt: running/disabled-Flags werden als Buchstaben vor dem
ersten Feld codiert, nicht als key=value; monitor-traffic liefert
"50.7kbps" statt einer reinen Zahl.
M19: Übersicht-Tab — animierte Flussrichtung auf allen Verbindungslinien
(TimelineView+dashPhase), frei verschiebbare Knoten mit Live-folgenden
Linien, Zurücksetzen-Button.
Zusätzlich (noch nicht live getestet, nur Build+Unit-Tests grün):
LAN-Port-Konflikt-Prüfung im Einrichten-Assistenten mit doppelter
Sicherheitsbestätigung, "Fertig"-Button nach erfolgreichem Anwenden.
82 Tests grün. HANDOFF.md/README.md/Manual.md/CHATLOG.md aktualisiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YDmUd93KxsYGr2kLTotWnG
Verbinden-Tab zeigt jetzt die volle Routerboard-Info (Modell/Revision/
Seriennummer/Firmware, aus /system routerboard) sowie einen
RouterOS-Software-Update-Check (/system package update: Kanal/
installierte/neueste Version/Status, "Jetzt pruefen"/"Update
installieren"), dazu "Firmware aktualisieren" fuer die
Routerboard-Bootloader-Firmware und "Jetzt neu starten" danach. Alle
vier Aktionen live bestaetigt, inklusive der zuvor unsicheren Frage, ob
/system routerboard upgrade's normalerweise interaktive Bestaetigung
den nicht-interaktiven SSH-Weg dieser App blockiert (tut es nicht).
Bug 20 gefunden und gefixt: fetchMenuItems' Singleton-Fallback (Bug 8)
reagierte nur auf eine geworfene Exception fuer "bad parameter terse",
aber RouterOS liefert diesen Fehler fuer /system routerboard mit
Exit-Code 0 zurueck (dasselbe Bug-10-Muster, diesmal beim Lesen statt
Schreiben) - die Routerboard-Sektion blieb dadurch leer, ohne Fehler.
Fix: zusaetzlich den Output-Text selbst pruefen, nicht nur die Exception.
Design-Durchgang: Verbinden-Detailseite/Sicherungen/Geraete liefen auf
nackter List ohne Rahmen - umgestellt auf Form+.formStyle(.grouped),
denselben nativen macOS-Karten-Look, den Wizard und Experte-Tab schon
hatten, fuer eine einheitliche App. Dark Mode auf Nachfrage gepueft und
ohne Codeaenderung bestaetigt funktionierend.
HANDOFF.md/CHATLOG.md aktualisiert: M14, Bug 20, Design-Durchgang,
Dark-Mode-Bestaetigung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CTgRxJTzaQwaRkngbaE1GJ
Größte offene Härtungslücke geschlossen: SSHTransport nutzte bisher
.acceptAnything() für Host-Key-Validierung, akzeptierte also jeden
Schlüssel ohne Prüfung -- ein Man-in-the-Middle im lokalen Netz wäre
unbemerkt geblieben. Jetzt Trust-on-first-use wie beim REST-Zertifikat:
- SSHHostKeyFingerprint: SHA256 über NIOSSHPublicKey.write(to:) (die
SSH-Wire-Format-Bytes des Schlüssels) -- exakt die Bytes, die auch
OpenSSH für seine SHA256:-Fingerabdrücke hasht. Per Unit-Test gegen
einen echten ssh-keygen-erzeugten Testschlüssel kreuzgeprüft
(SHA256:Hllxv6LLoHl2XTIXGGjUYJHbPFoH2F7iMrR74C5J95g), nicht geraten.
- SSHHostKeyTrustStore: UserDefaults-Persistenz pro Host, Pendant zu
CertificateTrustStore.
- SSHTransport conformt jetzt selbst zu NIOSSHClientServerAuthentication-
Delegate (wie RestTransport zu URLSessionDelegate) und übergibt sich
selbst als .custom(self) Host-Key-Validator.
- ConnectionService: neuer State .needsSSHHostKeyConfirmation, eigener
Bestätigungs-Retry-Pfad (trustCurrentSSHHostKeyAndRetry), analog zum
bestehenden Zertifikat-Flow.
- ConnectView: zweiter Bestätigungsdialog mit Warnhinweis, dass ein
geänderter Fingerabdruck bei zuvor schon verbundenen Routern auf ein
manipuliertes Netzwerk hindeuten könnte.
BackupService/FactoryResetService bekommen die TOFU-Prüfung automatisch
mit (SSHTransport-Default-Parameter, gleicher UserDefaults-Speicher),
ohne eigene Bestätigungs-UI -- in der Praxis unkritisch, da der
Verbinden-Tab das Vertrauen immer zuerst herstellt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW
Neuer "Einrichten"-Tab führt durch Internet-Anschluss (DHCP/statisch/
PPPoE) und Heimnetzwerk+DHCP-Server, zeigt vor dem Anwenden eine
Klartext-Übersicht (optional mit den exakten RouterOS-Befehlen) und
erstellt automatisch eine Sicherung, bevor Änderungen geschrieben
werden. Änderungen laufen über beide Transporte: CLI-Zeile für SSH,
JSON-POST für REST — beide aus einem gemeinsamen RouterOSCommand
gebaut. RouterOS-CLI-Syntax ist Standard und langjährig stabil, aber
nicht gegen ein echtes Gerät verifiziert; deshalb die Detailanzeige
im Übersichtsschritt vor dem Anwenden.
ConnectionService ist jetzt der einzige App-weite Zustand (ersetzt
SessionStore) und wird explizit an alle drei Tabs durchgereicht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW
XcodeGen-basiertes SwiftUI-Projekt für den RouterOS-Interview-Assistenten.
Erster Wizard-Schritt: Verbindung zu Mikrotik-Geräten per REST-API
(RouterOS >=7.1) mit SSH-CLI-Fallback für ältere Firmware, Zertifikats-
TOFU-Bestätigung, Zugangsdaten im Keychain. Unit-Tests für CLI-Parser
und Fallback-Logik.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HReLXMbmPvtQ23p1iWiJNW
