Eine native grafische Shell für SSH

 (probablymarcus.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn Server und Edge-Geräte statt nur eines Terminals eine browserbasierte grafische Shell bereitstellen, lassen sich Remote-Apps von anderen Geräten aus natürlicher nutzen
  • Diese Shell bietet einen App-Startbildschirm und eine URL-Lookup-API zwischen Apps, sodass sich ein Ablauf schaffen lässt, bei dem Dateien oder Ressourcen an die passende App weitergereicht werden
  • Apps stellen ihre UI über kleine HTTP-Server bereit, laufen jedoch nicht als allgemein öffentlich zugängliche Webserver, sondern hauptsächlich als private Server mit SSH- oder lokalem Zugriff als Voraussetzung
  • Die Verschlüsselung muss nicht von jeder App selbst implementiert werden, sondern kann der SSH-Schicht überlassen werden, sodass jeder App-Server mit wenigen Abhängigkeiten eine einfache Struktur beibehalten kann
  • Lewis hat dafür Outer Loop zu einem SSH-Browser gemacht und die Open-Source-Lösung Outer Shell veröffentlicht, wobei sowohl HTML-Apps als auch native outerframe-Apps vorgesehen sind

Eine grafische Shell über SSH

  • Webbrowser sind bereits ein gut etabliertes Beispiel für einen Ablauf, bei dem ein Gerät, der Server, einem anderen Gerät, dem Client, ein Nutzungserlebnis bereitstellt
  • Überträgt man denselben Ansatz auf Server und Edge-Geräte, können auch in Remote-Umgebungen statt terminalbasierter Apps grafische Apps verwendet werden
  • Die Shell stellt einen Startbildschirm für Apps bereit, und jede App liefert ihre Web-Benutzeroberfläche über einen kleinen HTTP-Server aus
  • Die Shell-API ermöglicht es Apps, die URLs anderer Apps zu finden, und schafft so Verbindungen zwischen ihnen
    • Registriert sich eine App beispielsweise als Texteditor, kann in einer anderen App per Doppelklick auf eine Textdatei genau diese Editor-App zum Öffnen verwendet werden
  • Apps können entweder bestehende HTML-basierte Web-Apps oder native outerframe-Apps sein

Umsetzungsweise und veröffentlichte Projekte

  • App-HTTP-Server laufen in der Regel als private Server, auf die andere Geräte im Netzwerk normalerweise nicht zugreifen können
    • Nutzer verwenden sie über SSH oder lokal
    • Anders als bei den meisten bestehenden webbasierten Server-Tools werden statt localhost-Ports vor allem Unix-Domain-Socket-Dateien verwendet
    • Unix-Domain-Socket-Dateien sind Ports ähnlich, existieren jedoch im Dateisystem und besitzen explizite Benutzerberechtigungen
  • Jeder HTTP-Server muss die Verschlüsselung nicht selbst verarbeiten
    • Die Verschlüsselung wird in der SSH-Schicht verarbeitet
    • Dadurch kann jeder App-Server ohne Abhängigkeiten sehr einfach bleiben
  • Outer Loop wurde als SSH-Browser für eine solche grafische Shell entwickelt
  • Die Open-Source-Lösung Outer Shell wurde veröffentlicht
  • Die zugehörige Dokumentation ist in drei Bereiche gegliedert
  • Funktionen wie Unix-Socket-Verbindungen im Browser galten bislang als sehr spezielle Nischenfunktionen, doch in Kombination mit Features wie SSH- und sudo-Erkennung entstehen neue technische Möglichkeiten
  • Einzelne serverartige Web-Apps wie Jupyter und Tensorboard sind zwar entstanden, nutzten jedoch jeweils einmalige Sicherheitsprotokolle, sodass sich kein gemeinsamer Weg etabliert hat, sie „richtig“ weiterzureichen
  • Da KI inzwischen beim Schreiben von Code helfen kann, ist es praktikabel geworden, dass jede App eine Codebasis für ihre Zielplattformen besitzt; für Lese- und leichte Apps wird HTML genutzt, für produktive Apps plattformspezifische native Apps — vorgeschlagen als natürliche Web-Architektur

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Meinungen auf Hacker News

  • Es ist ziemlich frustrierend, wie viele Reaktionen diese Idee kleinreden. Ein großer Teil der HN-Leserschaft scheint immer noch in einem TUI-Überlegenheitsdenken festzustecken und sich kaum für GUIs zu interessieren.
    Zwei Punkte sind zentral: Eine TUI ist einer GUI nicht grundsätzlich überlegen, und SSH sollte als Transportschicht nicht nur pty-Weiterleitung, also die TUI-Darstellungsschicht, unterstützen, sondern auch eine GUI-Darstellungsschicht.
    Tatsächlich waren diese beiden Dinge unter UNIX schon vor 30 Jahren umgesetzt, und mit dem X-Protokoll und ssh -X gab es auch eine Lösung. Aber X hat sich nicht durchgesetzt, und die Zukunft, in der man sich per ssh -X auf einer entfernten Maschine anmeldet, gnome-control-center startet und dann über ein Einstellungsfenster den entfernten Rechner konfiguriert, ist nie eingetreten. Wer glaubt, dass das funktioniert, kann es selbst ausprobieren; die Erfahrung ist erbärmlich.
    Trotzdem gab es diesen Bedarf weiterhin, und Apps wie Jupyter Notebook wurden zunehmend als Webserver umgesetzt. Das Dokumentformat, Styling und die clientseitige Skriptsprache des Webs sind trotz all ihrer Nachteile als Darstellungsschicht für interaktive Apps brauchbar geworden, und weil das Web ursprünglich von entfernten Dokumenten ausging, ist Netzwerktransparenz eingebaut.
    Wenn man sich Electron-Apps ansieht, muss man anerkennen, dass der HTML/CSS/JS-Stack auch bei Desktop-Apps eine dominierende Stellung eingenommen hat, und es liegt nahe, ihn als Darstellungsschicht für entfernte Apps über SSH zu nutzen. Dieses Projekt scheint ebenfalls in diese Richtung zu gehen.
    Auch bei Electron-Apps sind Display-Server und Client wie bei X getrennt; sie heißen dort „renderer process“ und „main process“ und kommunizieren per IPC. Theoretisch könnte man den main process und den renderer process auf unterschiedlichen Maschinen laufen lassen, wenn es nur ein geeignetes IPC-Transportmittel gäbe; das wirkt gar nicht so anders als diese Idee.

    • Es gibt auch Thinlinc, NoMachine, X2Go und Ähnliches, und alle nutzen SSH als wichtiges Backend. Die Idee ist ziemlich verbreitet.
    • ssh -X funktioniert je nach verwendetem Toolkit sowie Distanz/Latenz gut. Gtk ist wegen seiner Rendering-Pipeline zum Beispiel nicht gut geeignet.
      Wenn Distanz und Latenz groß genug werden, muss man sich überlegen, wie man das dem Nutzer präsentiert. Physikalische Grenzen lassen sich unabhängig vom Medium nicht vermeiden. Jedes Tool, das Remote-Grafikzugriff verspricht, muss mit Latenz im Hinterkopf entworfen werden. Dass vim auch bei Latenz gut funktioniert, liegt im Grunde daran, dass Befehle in eine Queue gestellt und gesendet werden.
    • Man kann Wayland über SSH ähnlich wie X-Forwarding nutzen; das heißt waypipe. Diese Zukunft ist also nicht tot.
    • Persönlich bin ich froh, dass die Zukunft, in der man per ssh -X das gnome-control-center einer entfernten Maschine öffnet und damit Server konfiguriert, nicht eingetreten ist. Server per GUI zu konfigurieren ist eine abscheuliche Vorgehensweise und sollte der Windows-Welt vorbehalten bleiben.
    • Es ist auch ziemlich nervig, dass der erste Kommentar immer darin besteht, andere Kommentatoren anzugreifen und ihre Gedanken herabzusetzen.

  • Das wirkt wie eine Lösung auf der Suche nach einem Problem, etwas, das es früher schon oft gab. Das folgende Zitat scheint gut zu diesem Versuch zu passen:
    „Wer Unix nicht versteht, ist dazu verdammt, es schlecht neu zu erfinden.“ ~Henry Spencer

    • Wir haben einen Programmierer eingestellt, ihm einen Linux-Laptop gegeben und ihn ein paar Dinge einrichten lassen. Nach ein paar Stunden fragte er, wo er PuTTY herunterladen könne. Da wurde mir klar, dass wir im Vorstellungsgespräch etwas Wesentliches übersehen hatten.
    • Nein. Jetzt, da mehr Menschen Linux verwenden, werden User-Experience-Entscheidungen, die vor 40 Jahren getroffen wurden, häufiger infrage gestellt.
      Auf fast jeder für Entwickler gedachten Maschine ist ein SSH-Server installiert und erreichbar.
      Warum muss ein SSH-Terminal wie textbasierter Müll aus den 1960ern aussehen? Warum sollte eine TUI das Beste sein, was man über SSH schicken kann? Warum kann man im Terminal keinen 4K-Film ansehen oder per Pinch-Zoom durchs Web navigieren?
    • Das wirkt wie ein ziemlich hartes Urteil. Es gibt tatsächlich eine Usability-Lücke, und dieses Projekt versucht, daran zu rühren.
      Die Idee, Linux-Verzeichnisse über SSH mit nativen UI-Komponenten anzusehen, klingt zum Beispiel ganz ordentlich.
      Allerdings wirken Teile davon auch wie Probleme, die bereits auf andere Weise gelöst wurden, etwa durch ein sshfs-Mount.
    • Der Teil mit „Leute, die Unix nicht verstehen“ ist hier eher das eigentliche Grundproblem.
      Das erinnert an einen alten Artikel über programmierbare Thermostate. Sie waren so mächtig, dass man sie sehr detailliert einstellen konnte, aber für die meisten Menschen grauenhaft zu benutzen. Die Kernaussage war in etwa: „Die Leute wollen nicht dein obskures System lernen, sie wollen den Nutzen, den dieses System verspricht.“ Eine gute UI muss diese Lücke minimieren können.
    • Das hier wirkt eher wie Plan 9 als wie UNIX. Man muss UNIX nicht zu sehr verehren.

  • Die Idee, Frontend und Backend grafischer Apps zu trennen, ist gut. Aber wirklich neu wirkt sie nicht; vielleicht übersehe ich auch etwas.
    Es sieht so aus, als kenne man X11Forwarding yes oder html5 web app nicht.
    Dinge wie die Fähigkeit eines Browsers, sich mit einem Unix-Socket zu verbinden, wurden als extrem nischig abgelehnt.
    Das wurde wegen Sicherheitsproblemen nicht implementiert. Zumindest gilt das für rohe Unix-Sockets; andere Ports, die auf WebSocket oder HTTP beschränkt sind, sind möglich.

    • Kurz zur Sicherheit: Die Diskussionen, die ich in mehreren Mozilla-Foren gesehen habe, liefen ungefähr so ab:
      Man kann Browsern nicht erlauben, sich mit beliebigen Sockets zu verbinden. Viele Sockets wollen ausdrücklich keine Browser-Verbindungen, oder sie sind sich gar nicht bewusst, dass Browser sich verbinden könnten.
      Also müsste man eine Art Allowlist hinzufügen, und dann würde es für so eine Nischenfunktion zu kompliziert.
      Deshalb glaube ich, dass der Kernpunkt die Nischenhaftigkeit war.
      Zum Vergleich: Outer Loop fügt eine Allowlist hinzu: https://outerloop.sh/unix-domain-sockets/

  • Ich versuche gerade zu verstehen, wie Outer Shell hier funktioniert. Auf der Website wird die Motivation so beschrieben:
    Apps wie Jupyter oder TensorBoard sind, wenn sie auf einem Remote-Server laufen, normalerweise nicht im normalen Webbrowser sichtbar. Denn es wäre sehr riskant, dem gesamten Internet Zugriff auf diese Apps zu geben. Stattdessen laufen sie auf einem lokalen Port des Servers, und mein Computer kann nicht direkt darauf zugreifen.
    Traditionell musste man dafür angeblich ein neues Terminal öffnen und Befehle wie ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com & ausführen.
    Stimmt das? Normalerweise nutzt man solches SSH-Forwarding doch nur beim Prototyping, und für die Bereitstellung richtet man eine Website wie myjupyternotebook.com ein und hängt Authentifizierung davor, damit andere nicht darauf zugreifen können. HTTP Basic Auth ist auch keine so große Sache.
    Wenn man nicht HTTP, sondern SSH öffentlich exponieren möchte, gibt es auch andere Optionen, etwa hinter einem VPN oder Tunnel.
    Outer Loop ist sehr cool, aber ich verstehe nicht so recht, warum es nötig ist. Ich habe das Gefühl, etwas zu übersehen, daher würde ich gern verstehen, warum es gebaut wurde.

    • Ich glaube, es gibt unterschiedliche Gruppen von Leuten, die Server, SSH usw. nutzen.
      Ich bin eher bei Anwendungsfällen wie Deep-Learning-Experimenten, GPU-Kernel-Optimierung und Roboterentwicklung. Ein Roboter ist letztlich nur ein Server, der sich bewegt, und in solchen Fällen nutzt man ausdrücklich einen Remote-Computer.
      Für Leute aus dieser Gruppe dürfte sich dieses Tool intuitiver anfühlen als der von dir vorgeschlagene Ablauf. Vielleicht projiziere ich da aber auch nur meine eigenen Gedanken hinein.
      Für mich fühlt sich das wie eines dieser grundlegenden Dinge an, die existieren können. Wie ein Remote-first grafisches Betriebssystem.
    • Wenn es nur einen Benutzer gibt, nämlich einen selbst, und man nur vom Desktop-Betriebssystem aus auf Dienste zugreift, wirkt es so, als würde es einem die Mühe mit Reverse Proxy und TLS-Zertifikaten ersparen.
    • Wenn du viele Ports per SSH weiterleitest, könntest du auch in Betracht ziehen, SSH einen SOCKS5-Proxy starten zu lassen.
      ssh -D 4711 -q -C -N user@host
      Damit wird localhost:4711 zu einem SOCKS5-Proxy, den du im Browser angeben kannst.
      Natürlich ist ein WireGuard-VPN besser. Vor allem multiplexed SSH alles über eine einzige TCP-Verbindung, sodass bei Verlust eines Pakets der gesamte Forwarding-Traffic unter Head-of-line Blocking leidet, bis es erneut übertragen wurde.
    • HTTP Basic Auth ist nicht sicher.
    • SSH-Port-Forwarding nutze ich hauptsächlich dann, wenn ein Netzwerk durch irgendeine Fehlkonfiguration kaputt ist und man es retten muss.

  • Der Autor scheint Cockpit nicht zu kennen.
    Die Dinge, von denen er sagt, es gebe sie „nicht“ oder sie seien „neu“, stecken seit über 10 Jahren in Cockpit. Socket-basierte Webserver-Verbindungen, die Trennung von Backend und Frontend bei Server-Apps, bis hin zur Idee einer Server-Konsole mit Shell-Zugriff.
    Auf die Frage „Ist es nicht seltsam, dass es das noch nicht gibt?“ würde ich antworten: Nein. Denn das gibt es schon seit Langem.

    • „Seien Sie freundlich. Seien Sie nicht schnippisch. Unterhalten Sie sich neugierig, statt nachzubohren. Streichen Sie Sarkasmus.“
      Mit freundlichen Grüßen,
      die HN-Richtlinien-Polizei :-)
      https://news.ycombinator.com/newsguidelines.html
    • Wenn ich mich nicht irre, ist Cockpit eine Web-UI und führt keinen nativen Code aus. Das ist ein wichtiger Unterschied.
    • Von Cockpit habe ich auch noch nie gehört. Was ist das?

  • Toller Artikel. Ich lege ihn mir für meine Recherchen als Bookmark ab.
    Die „clickity clackity“-Funktion [0] meines Terminals ist an die lokale Maschine gebunden; sobald ich remote gehe, verschwindet der grafische Charakter.
    Das ändert sich dank Offline Replay [1] langsam. Dabei arbeiten native GUI und TUI zusammen und ermöglichen Funktionen wie Zurückspulen. Aber es ist noch ein weiter Weg, und es ist schön zu sehen, dass andere ernsthaft damit experimentieren. Das Terminal ist ein stark vernachlässigter Bereich.
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • Leute, die mit dem Terminal vertraut sind, vergessen, wie feindselig SSH für Menschen ist, die es nicht an der Uni gelernt haben.
    Wenn das die Einstiegshürde für kleine Teams senken kann, die einen VPS betreiben, ohne gleich jemanden für die Plattform einzustellen, ist es ein Erfolg. Mich würde allerdings interessieren, wie Schlüssel und Jump Hosts behandelt werden.

  • Großartig. Das geht eindeutig in die richtige Richtung.
    Die Entkopplungsschicht zwischen Frontend und Backend sollte am kleinstmöglichen „Stück“ angesetzt werden.
    Viele der hier sarkastischen Leute würden es verstehen, wenn sie die Latenz und den zusätzlichen Overhead selbst „spüren“ würden. Es wurde nicht genug darüber nachgedacht, die Daten passend zum jeweiligen Use Case sorgfältig zuzuschneiden.
    Darüber hinaus hätte die top-App in der Demo, bei der „die Einstellungen häufig bewegt werden, um Last zu erzeugen“, meiner Meinung nach mehr Rendering clientseitig per JIT erledigen sollen. Dann wäre die Information, die zwischen Pi und Client hin- und hergeht, auf etwa komprimierte Deltas der ps-Ausgabe reduziert worden.

  • So sollte man das nicht machen. Es gibt viele alte, gute Sicherheitsgründe und Gründe der Isolation der Web-Control-Plane, warum man Browsern keine allgemeinen Socket-Berechtigungen gibt.
    Die mechanisch naheliegendste Analogie ist, warum dreirädrige ATVs eine schlechte Idee sind.

    • Unter den folgenden Bedingungen fände ich es in Ordnung:
      Sockets müssen standardmäßig blockiert sein und dürfen erst geöffnet werden, nachdem sie serverseitig ausdrücklich auf eine Allowlist gesetzt wurden.
      Es muss ein echtes sudo-Verständnis geben, sodass man ohne sudo-Passwort nicht an Root-Sockets herankommt. Diese Funktion ist wichtig, weil sonst ein Anreiz entsteht, Root-Backends über für Benutzer zugängliche Sockets laufen zu lassen.
      Weitere Details gibt es hier: https://outerloop.sh/security/