Hosts und Verbindungen

Ein Host ist mehr als eine Adresse: Protokoll, Zugang, Schlüssel, Sprunghost, Weiterleitungen, Umgebungsvariablen und die Gruppe, in der er steht. Alles davon wird verschlüsselt abgeglichen.

SSH oder Remote Desktop

Ein Host trägt sein Protokoll. Ganz oben im Formular steht die Wahl zwischen SSH und Remote Desktop, und davon hängt ab, welche Felder darunter überhaupt eine Bedeutung haben. Gruppen, Tags, Kennfarbe, Sprunghost und Sortierung gelten für beide gleichermaßen — es ist dieselbe Hostliste, nicht eine zweite daneben.

Feld SSH Remote Desktop
Üblicher Port223389
Schlüsselja
Domäneja
Auflösung, Skalierung, Farbtiefeja
Zwischenablage, Tonja
Port-Weiterleitungenja
Umgebungsvariablenja
Snippet nach dem Verbindenja

Was ohne Shell nichts bedeutet, verschwindet beim Umschalten, statt wirkungslos dazustehen. Ein Auswahlfeld, das nichts bewirkt, ist schlimmer als keines: man trägt etwas ein und wundert sich, dass nichts passiert.

Der Port zieht beim Umschalten mit — aber nur, wenn dort noch die Vorgabe des alten Protokolls steht. Wer 13389 eingetragen hat, meint 13389.

Erst alle Geräte aktualisieren, dann RDP-Hosts anlegen. Ein Gerät mit einer älteren Version zeigt einen Remote-Desktop-Host als SSH-Host auf Port 3389 an. Es kann ihn anzeigen und verbinden versuchen — schreibt es ihn aber zurück, gehen Protokoll und alle Bildschirm-, Zwischenablage- und Toneinstellungen verloren, und der Host ist danach ein SSH-Host. Das ist der bekannte Preis additiver Felder, hier mit einer schärferen Folge als sonst.

Anlegen

Pflicht sind Name und Adresse. Alles andere hat brauchbare Vorgaben. Beim Benutzer steht bewusst eine Auswahl statt eines Textfeldes: root auf achtzehn Hosts ist achtzehnmal derselbe Zugang, und wer ihn jedes Mal neu tippt, tippt ihn irgendwann falsch.

Wer einen neuen Benutzer braucht, tippt ihn und setzt einen Haken — dann steht er beim nächsten Mal in der Liste. Ein Passwort dazu ist freiwillig; ohne eines wird beim Verbinden gefragt.

„Kein Passwort“ ist nicht „leeres Passwort“. Ein leerer String würde als hinterlegtes Passwort gelten, die Rückfrage bliebe aus und die Anmeldung schlüge fehl, ohne dass jemand etwas eingeben durfte. Er wird deshalb zu null.

Gruppen und Tags

Gruppen können ineinander liegen. Zugeordnet wird mit der Maus: einen Host auf eine Gruppe ziehen steckt ihn hinein. Während gezogen wird, erscheint über der Liste ein Streifen Aus der Gruppe nehmen — der Weg zurück, der sonst keinen sichtbaren Ort hätte.

Drei Dinge, die dabei nicht passieren dürfen und deshalb geprüft sind:

Auf dem Desktop greift das Ziehen sofort, auf mobilen Geräten erst nach langem Drücken: dort ist Wischen das Scrollen.

Tags sind frei erfundene Wörter und quer zur Gruppenstruktur. Ein Host kann beliebig viele tragen; Snippets können sich darauf beziehen.

Kennfarben

Fünf Farben aus der Markenpalette, mehr nicht. Eine Liste mit dreißig Hosts in dreißig Farben ist nicht sortiert, sondern bunt. Gespeichert wird der Name der Farbe, nicht ihr Wert — ein Hex-Wert in der Datenbank wäre ein zweiter Ort, an dem Farben stehen.

Port-Weiterleitung

Drei Arten, wie bei OpenSSH. Sie hängen am Host, starten mit der Sitzung und fallen mit ihr weg.

ArtBedeutung
-LEin Port hier zeigt auf einen Dienst dort.
-RUmgekehrt: ein Port dort zeigt auf einen Dienst hier.
-DSOCKS5-Proxy hier, der durch die Sitzung geht.

Die Zeile im Formular zeigt neben den Feldern die Kurzschreibweise, wie man sie auf der Kommandozeile schriebe. Wer -L localhost:8080 → db:5432 liest, sieht sofort, ob es herum stimmt: Der Fehler an dieser Stelle ist immer derselbe, nämlich vertauschte Ports.

Wer an alle Schnittstellen bindet, bekommt einen Hinweis. Ein Datenbankport aus einem Rechenzentrum, der versehentlich im ganzen WLAN steht, ist der Unterschied zwischen einem Werkzeug und einem Vorfall.

Sprunghost

Ein Host kann über einen anderen verbunden werden, und der wieder über einen dritten — Ketten sind erlaubt. Der Sprunghost ist dabei ein Host wie jeder andere: eigener Schlüssel, eigener Zugang, eigene Host-Key-Prüfung. Wer dort sitzt, sieht jede Verbindung, die durchgeht; ihn weniger streng zu prüfen als das Ziel wäre die falsche Sparsamkeit.

Ringe — A springt über B, B über A — entstehen nur durch einen Sync und werden beim Auflösen abgefangen.

Neu verbinden

Bricht eine Verbindung ab, versucht tessera es von selbst: nach 2, 5, 15, 30 und 60 Sekunden. Ein sauberes exit ist kein Abbruch und löst nichts aus.

Scheitert ein Versuch, steht der Grund im Puffer und unten im Band — jeder Grund: verweigerte Shell, abgelehnte Weiterleitung über den Sprunghost, Schlüssel mit falscher Passphrase, abgebrochener Handshake. Ein Tab bleibt nie auf „Verbindung wird aufgebaut“ stehen. Solange dort etwas stünde, was nie ankommt, gäbe es weder eine Meldung noch den Knopf Neu verbinden.

Bekannte Host-Schlüssel

Beim ersten Verbinden wird der Fingerabdruck angezeigt und nach Bestätigung gespeichert. Ändert er sich später, bricht die Verbindung ab. Es gibt kein „trotzdem verbinden“.

Der Warnhinweis zeigt beide Fingerabdrücke untereinander — den gemerkten samt Datum des Erstkontakts und den, der gerade angeboten wird. Stimmt der neue mit dem überein, den der Server selbst nennt, ersetzt Gemerkten Schlüssel ersetzen den Eintrag an Ort und Stelle. Den Umweg über die Einstellungen braucht es dafür nicht mehr.

Ersetzt wird dabei nur der Eintrag. Verbunden wird nicht: Der nächste Versuch ist ein eigener Klick. Wer sich vertan hat, hat dann einen falschen Eintrag in der Liste — aber noch keine Sitzung an einen Fremden gegeben. Ein Dialog, der „ersetzen und weiter“ anböte, wäre einer, den man wegklickt, um weiterzukommen.

Ein geänderter Host-Schlüssel ist entweder eine Neuinstallation oder ein Angriff, und die Unterscheidung trifft nicht der Client. Deshalb steht die Frage so da: mit beiden Zahlen zum Vergleichen und ohne vorausgewählte Antwort.

Welche Verschlüsselung ausgehandelt wird

tessera bietet in dieser Reihenfolge an: chacha20-poly1305@openssh.com, dann aes256-ctr und aes128-ctr, dahinter die beiden GCM-Verfahren. aes*-cbc steht ganz hinten und wird nur erreicht, wenn ein Server nichts anderes kann.

Der Grund ist nicht Sicherheit, sondern Geschwindigkeit. AES rechnet erst dann schnell, wenn die CPU es selbst kann — der Client rechnet es in Dart nach. Gemessen bleiben von AES-GCM 1,4 MB/s übrig, während ChaCha20-Poly1305 auf demselben Rechner 85 MB/s schafft. Das ist der Unterschied zwischen Sekunden und Minuten, und weil die Entschlüsselung im selben Faden läuft wie die Oberfläche, stünde die währenddessen still.

Schwächer wird dabei nichts. ChaCha20-Poly1305 ist ebenfalls ein AEAD-Verfahren, AES-CTR läuft mit Encrypt-then-MAC, und beide gelten unverändert als stark. Schlüsseltausch, Host-Schlüssel-Verfahren und MAC bleiben unangetastet.

Import aus OpenSSH und PuTTY

Vorhandene Konfigurationen lassen sich übernehmen: aus ~/.ssh/config samt Host-Mustern, ProxyJump und IdentityFile, und aus der Registry-Ablage von PuTTY. Was nicht sauber abgebildet werden kann, wird gemeldet statt stillschweigend verworfen.