Von Termius zu Termix: die SSH-Konsole ins eigene Haus holen

Ein SSH-Client ist das Werkzeug, das ein Administrator im Laufe des Tages am häufigsten öffnet. Jahrelang war das bei uns Termius: ansprechend gestaltet, zwischen Arbeitsplatz und Telefon synchronisiert, mit Ordnern, geteilten Zugangsdaten und einer Befehlsbibliothek. Im September haben wir ihn durch Termix ersetzt, eine Open-Source-Webkonsole, die in unserem eigenen Administrationsnetz läuft. Es geht dabei nicht um Funktionen: Termius hat mehr davon. Es geht darum, wer was in der Hand hat.

Was man einem SSH-Client als SaaS anvertraut #

Sehen Sie sich an, was Ihr SSH-Client enthält: die vollständige Liste Ihrer Maschinen mit Adressen, Ports und Konten. Ihre privaten Schlüssel, sofern Sie der Synchronisierung zugestimmt haben. Ihre Passwörter, Ihre Befehlsschnipsel, manchmal Ihre Tunnel. Das ist wortwörtlich die Landkarte Ihres Informationssystems samt den Mitteln, hineinzukommen. Bei einem SaaS-Anbieter wird all das über seine Server verschlüsselt und synchronisiert, außerhalb der Europäischen Union, im Rahmen eines Abonnements. Wir haben keinen Grund, an der Qualität dieser Verschlüsselung zu zweifeln. Aber wir hatten keine Möglichkeit, sie zu prüfen, keine Kontrolle über den Standort und eine Abhängigkeit mehr für den Tag, an dem sich das Abonnement, der Anbieter oder seine Richtlinien ändern. Für eine Serverflotte, die wir Kunden als in Frankreich gehostet und administriert in Rechnung stellen, war das ein Widerspruch, den wir schon viel zu lange mit uns herumtrugen.

Termix: eine Webkonsole bei uns #

Termix (Termix-SSH/Termix) ist eine selbst gehostete Webplattform: SSH-Terminal mit mehreren Tabs, Dateimanager, Tunnel, Remote-Desktop über Guacamole, Docker-Integration, Sitzungsaufzeichnung und eine mobile App. Alles in einem Container, auf eine bestimmte Version festgelegt, mit einer im Ruhezustand verschlüsselten SQLite-Datenbank. Wir haben es auf einer kleinen Debian-13-VM in unserem Administrationsnetz installiert, nach zwei Grundsätzen: kein lokales Passwort (Anmeldung ausschließlich über unseren IdP Authentik, als zwölfter angebundener Dienst) und kein Schlüssel, der die Server direkt öffnet (dazu weiter unten mehr).

⟷ seitlich scrollen

42 Hosts eintragen, ohne sie abzutippen: die API und die richtige Quelle #

42 Einträge von Hand abzuschreiben ist der sicherste Weg, Fehler einzubauen. Deshalb haben wir das Inventar über die API von Termix importiert, in zwei Durchgängen: zuerst den Sprung-Host (die 26 Maschinen des internen Netzes laufen über ihn), dann die Clients dieses Sprung-Hosts, weil ein Eintrag nur auf einen bereits vorhandenen Sprung-Host verweisen kann. Ordner pro Zone, ein gemeinsam genutzter Zugangsdatensatz und eine unverzichtbare Einstellung: Der Benutzername im Host-Eintrag muss Vorrang vor dem des Zugangsdatensatzes haben, sonst meldet sich die gesamte Flotte als root an, obwohl sie mit vier verschiedenen Konten arbeitet.

Erste Lehre, und sie betrifft nicht Termix: Der Import beruhte auf dem, was der Cluster meldet (der API des Hypervisors), nicht auf unserer Inventardatei. Das hat sich gelohnt: Die Datei enthielt vier Maschinen, die es nicht mehr gab, eine Adresse, die der falschen VM zugeordnet war, und zwei durchgestrichene Alteinträge. Um ein Werkzeug zu befüllen, gehen Sie immer von der maßgeblichen Quelle aus, nie von dem Dokument, das sie angeblich widerspiegelt.

Die Fallstricke, die die Dokumentation verschweigt #

• TLS ist nicht optional. Ohne ENABLE_SSL=true geht das Passwort im Klartext über die Leitung, und die Standardkonfiguration für CORS ist sehr freizügig. Die Dokumentation führt das als bekannte Schwachstelle; niemand liest es vor dem Vorfall.
• Die Verschlüsselung wird aus dem Passwort des Benutzers abgeleitet. Ein Passwort außerhalb einer Sitzung zurückzusetzen zerstört alle verschlüsselten Daten dieses Kontos. Folge: Legen Sie niemals das Konto eines Kollegen an seiner Stelle an.
• Die Umgebungsdatei entsteht mit den Rechten 644, mit dem JWT-Secret und dem Datenbankschlüssel darin. Sie müssen sie von Hand auf 600 zurücksetzen. Außerdem geht standardmäßig ein tägliches Nutzungssignal an den Hersteller, das sich in den Einstellungen abschalten lässt.
• Die Route für die Auflistung steht im Singular (/host/db/host); das offizielle Beispiel nennt den Plural, der 404 liefert. Schlimmer: /hosts liefert die Webanwendung mit 200 aus. Prüfen Sie den Content-Type, nie nur den Statuscode.
• Eine Massenaktualisierung meldet „43 aktualisiert, 0 fehlgeschlagen“ und ändert nichts, wenn das Feld nicht auf ihrer Positivliste steht. Verlassen Sie sich nie auf diesen Rückgabecode: Lesen Sie den Eintrag erneut.
• Die Sitzungsaufzeichnung lässt sich nicht abschalten, jedenfalls nicht in der Version, die wir nutzen: Der Schalter pro Host steht in der Dokumentation, aber nicht im Code der Routen. Wir leben damit, mit minimaler Aufbewahrungsdauer. Den Fehler haben wir an das Projekt gemeldet.

Die Falle, die fast den Bastion überflutet hätte #

Termix prüft regelmäßig, ob jeder Host antwortet, indem es eine TCP-Verbindung öffnet und wieder schließt. Gegenüber einem gewöhnlichen SSH-Server ist das harmlos. Doch unsere Einträge zielen nicht mehr auf die Server, sondern auf unseren Bastion, der jede Verbindung aufzeichnet. Vierzig Einträge, die alle sechzig Sekunden abgefragt werden, ergeben rund 5.200 Geistersitzungen pro Tag, 1,7 GB Aufzeichnungen täglich und einen Audit-Trail, der unter Rauschen begraben wird, das sich nicht von echten Verbindungen unterscheiden lässt. Die globale Einstellung kann die Abfrage nur verlangsamen (höchstens auf einmal pro Stunde), aber nicht abschalten. Sie müssen sie Eintrag für Eintrag deaktivieren und danach den Dienst neu starten, weil die Aktualisierung eines Eintrags die Timer nicht neu lädt.

// PUT /host/db/host/:id - auf jedem Eintrag setzen, danach Termix neu starten
{ "statsConfig": {
    "statusCheckEnabled": false,
    "metricsEnabled": false,
    "disableTcpPing": true
} }

SSO: zwei Überraschungen #

Die Anbindung an den IdP erfolgt über Umgebungsvariablen, mit automatischer Registrierung bei der ersten Anmeldung und Vergabe der Administratorrolle über die Mitgliedschaft in einer Gruppe. Zwei Überraschungen. Erstens: Die Rücksprung-URL wird aus dem Host-Header der Anfrage gebildet. Rufen Sie die Konsole über eine andere Adresse auf als die beim IdP hinterlegte, scheitert die Anmeldung mit 400. Zweitens, und das wiegt schwerer: Die Liste der zugelassenen Benutzer gilt nicht für das allererste Konto. Wer sich als Erster erfolgreich per SSO anmeldet, wird Administrator, unabhängig von der Allowlist. Die einzige echte Schranke ist also die Zuweisung der Anwendung auf der Seite des IdP: Erweitern Sie sie nie vor Ihrer eigenen ersten Anmeldung.

Was die Konsole nicht ist #

Es muss klar gesagt werden: Termix bringt Komfort, keine Sicherheit. Eine Webkonsole, die einen Schlüssel für 42 Maschinen hält, ist ein äußerst wertvolles Ziel, und genau das hatten wir in den ersten Tagen. Die Absicherung kam von anderer Stelle: Alle Einträge wurden auf unseren Warpgate-Bastion umgelenkt, und der Schlüssel von Termix wurde von den 42 Servern entfernt. Er dient nur noch dazu, sich beim Bastion auszuweisen; die Schlüssel des Bastions öffnen die Maschinen, und jede Sitzung wird dort aufgezeichnet. Die Konsole kann morgen verschwinden, nichts Wichtiges liegt darin. Darum geht es im nächsten Artikel.

Die Kontrolle über das eigene Administrationswerkzeug zurückzugewinnen gehört zu dem, was wir unter souveränen Managed Services verstehen: nicht nur in Frankreich hosten, sondern jederzeit wissen, wo die Landkarte Ihres Informationssystems liegt. Wenn Ihre in der Cloud eines SSH-Clients liegt, sprechen wir darüber.