Un shell graphique natif pour SSH

 (probablymarcus.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Si les serveurs et les appareils edge fournissaient un shell graphique basé sur le navigateur au lieu d’exposer seulement un terminal, les apps distantes pourraient être utilisées plus naturellement depuis d’autres appareils
  • Ce shell fournit un écran d’accueil des apps et une API de résolution d’URL entre apps, afin de créer des flux où fichiers ou ressources sont transmis à l’app appropriée
  • Les apps fournissent leur UI via un petit serveur HTTP, mais ne fonctionnent pas comme des serveurs web publics ordinaires : elles agissent comme des serveurs privés, principalement prévus pour un accès via SSH ou local
  • Le chiffrement peut être confié à la couche SSH au lieu d’être implémenté directement par chaque app, ce qui permet à chaque serveur d’app de conserver une structure simple avec peu de dépendances
  • Lewis a pour cela conçu Outer Loop comme navigateur SSH et publié l’open source Outer Shell, en pensant à la fois aux apps HTML et aux apps natives outerframe

Un shell graphique fonctionnant au-dessus de SSH

  • Le navigateur web est déjà un exemple bien établi du flux dans lequel un appareil, le serveur, fournit une expérience à un autre appareil, le client
  • En appliquant la même approche aux serveurs et aux appareils edge, il devient possible d’utiliser des apps graphiques même dans un environnement distant, plutôt que des apps en terminal
  • Le shell fournit un écran d’accueil pour les apps, et chaque app sert une interface utilisateur web via un petit serveur HTTP
  • L’API du shell permet aux apps de trouver leurs URL respectives et crée des connexions entre apps
    • Par exemple, si une app s’enregistre comme éditeur de texte, un double-clic sur un fichier texte dans une autre app peut l’ouvrir dans cette app d’édition
  • Une app peut être une app web existante basée sur HTML, ou une app native outerframe

Mode d’implémentation et projets publiés

  • Le serveur HTTP d’une app fonctionne généralement comme un serveur privé, inaccessible depuis d’autres appareils du réseau
    • L’utilisateur l’emploie via SSH ou en local
    • Contrairement à la plupart des outils serveur existants basés sur le web, il utilise principalement des fichiers de socket de domaine Unix plutôt que des ports localhost
    • Les fichiers de socket de domaine Unix sont similaires aux ports, mais existent dans le système de fichiers et disposent de permissions utilisateur explicites
  • Chaque serveur HTTP n’a pas besoin de gérer lui-même le chiffrement
    • Le chiffrement est pris en charge par la couche SSH
    • Cela permet à chaque serveur d’app de rester très simple, sans dépendances
  • Outer Loop a été conçu comme un navigateur SSH pour ce type de shell graphique
  • L’open source Outer Shell a été publié
  • La documentation associée est proposée en trois volets
  • Dans un navigateur, des fonctionnalités comme la connexion à des sockets Unix étaient considérées comme très spécialisées, mais combinées à des capacités comme la prise en charge de SSH et de sudo, elles ouvrent de nouvelles possibilités techniques
  • Des apps web individuelles de type serveur, comme Jupyter et Tensorboard, sont apparues, mais chacune utilise un protocole de sécurité ad hoc, et aucune méthode commune pour les transmettre « correctement » ne s’est imposée
  • Avec l’IA qui peut désormais aider à écrire du code, il est devenu pratique pour chaque app de disposer d’une base de code propre à chaque plateforme cible ; l’architecture web proposée paraît naturelle : HTML pour la lecture et les apps légères, et des apps natives adaptées à la plateforme pour les apps de travail

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis de Hacker News

  • C’est assez frustrant de voir autant de réactions dénigrer cette idée. Une grande partie du lectorat de HN semble encore prisonnière d’un suprémacisme TUI, avec peu d’intérêt pour les GUI
    Deux points sont essentiels. Les TUI ne sont pas intrinsèquement supérieures aux GUI, et SSH, en tant que couche de transport, devrait prendre en charge non seulement le transfert de pty, c’est-à-dire la couche d’affichage TUI, mais aussi une couche d’affichage GUI
    En réalité, ces deux points existaient déjà dans UNIX il y a 30 ans, avec le protocole X et la solution ssh -X. Mais X n’a pas gagné, et l’avenir où l’on se connecte à une machine distante avec ssh -X puis où l’on lance gnome-control-center pour voir apparaître une fenêtre de réglages permettant de configurer l’ordinateur distant n’est jamais arrivé. Si vous pensez que ça marche, essayez vous-même : l’expérience est désastreuse
    Ce besoin a pourtant perduré, et des apps comme Jupyter Notebook ont commencé à être développées sous forme de serveurs web. Le format documentaire du web, son styling et son langage de script côté client sont devenus, malgré tous leurs défauts, utilisables comme couche d’affichage pour des apps interactives ; et comme le web partait à l’origine de documents distants, la transparence réseau y est intégrée
    Quand on regarde les apps Electron, il faut reconnaître que la stack HTML/CSS/JS occupe aussi une position dominante dans les apps desktop, et il est naturel de l’exploiter comme couche d’affichage d’apps distantes via SSH. Ce projet semble aller dans ce sens
    Comme X, une app Electron sépare serveur d’affichage et client, appelés respectivement “renderer process” et “main process”, qui communiquent par IPC. En théorie, avec un moyen de transport IPC adapté, on pourrait exécuter le main process et le renderer process sur des machines différentes ; cela ne paraît pas très différent de cette idée

    • Il existe aussi Thinlinc, NoMachine, X2Go, etc., qui utilisent tous SSH comme backend principal. C’est une idée assez courante
    • ssh -X fonctionne bien selon le toolkit utilisé et la distance/latence. Par exemple, Gtk n’est pas idéal à cause de son pipeline de rendu
      Quand la distance et la latence deviennent suffisamment importantes, il faut réfléchir à ce que l’on présente à l’utilisateur. Quelle que soit le média, on ne peut pas échapper aux limites physiques. Tout outil qui promet un accès graphique distant doit être conçu en tenant compte de la latence. Si vim fonctionne bien même avec de la latence, c’est essentiellement parce qu’il empile les commandes dans une file avant de les envoyer
    • Comme le forwarding X, on peut utiliser Wayland au-dessus de SSH, cela s’appelle waypipe. Donc cet avenir n’est pas mort
    • Personnellement, je suis content que l’avenir consistant à lancer gnome-control-center sur une machine distante via ssh -X pour configurer un serveur ne soit jamais arrivé. Configurer un serveur avec une GUI est une manière détestable de faire, et j’espère qu’elle restera cantonnée au monde Windows
    • C’est aussi assez agaçant que le premier commentaire consiste toujours à accuser les autres commentateurs et à rabaisser leurs opinions

  • Cela ressemble à une solution en quête d’un problème, comme il y en a déjà eu beaucoup par le passé. La citation ci-dessous semble bien correspondre à cette tentative
    « Ceux qui ne comprennent pas Unix sont condamnés à le réinventer, en moins bien. » ~Henry Spencer

    • J’ai embauché un programmeur et lui ai donné un laptop Linux en lui demandant de faire quelques réglages ; quelques heures plus tard, il m’a demandé où télécharger PuTTY. C’est là que j’ai compris qu’il y avait eu une grosse lacune dans l’entretien
    • Non. Maintenant que davantage de gens utilisent Linux, des décisions d’expérience utilisateur prises il y a 40 ans sont davantage remises en question
      Presque toutes les machines destinées aux développeurs ont un serveur SSH installé et accessible
      Pourquoi un terminal SSH devrait-il ressembler à une cochonnerie en texte seul façon années 1960 ? Pourquoi les TUI devraient-elles être la meilleure chose à faire transiter par SSH ? Pourquoi ne peut-on pas regarder un film en 4K dans le terminal, ou parcourir le web avec un pinch-to-zoom ?
    • Cela me paraît un jugement un peu dur. Il existe réellement un manque en matière d’utilisabilité, et ce projet tente de s’y attaquer
      L’idée de visualiser des répertoires Linux via SSH avec des composants d’UI natifs, par exemple, semble intéressante
      Cela dit, une partie du problème semble déjà résolue autrement, comme avec un montage sshfs
    • La partie “ceux qui ne comprennent pas Unix” est justement le vrai problème de fond ici
      Cela me rappelle un ancien article sur les thermostats programmables. Il expliquait qu’ils sont assez puissants pour être configurés très finement, mais horribles à utiliser pour la plupart des gens. L’idée était proche de ceci : “les gens ne veulent pas apprendre votre système abscons, ils veulent les bénéfices que ce système promet”. Une bonne UI doit savoir minimiser cet écart
    • Cela ressemble davantage à Plan 9 qu’à UNIX. Il n’est pas nécessaire de vénérer UNIX à ce point

  • L’idée de séparer le frontend et le backend des apps graphiques est bonne. Mais difficile de dire que c’est nouveau ; peut-être que quelque chose m’échappe
    Il semble ne pas connaître X11Forwarding yes ni les html5 web app
    Des choses comme la capacité d’un navigateur à se connecter à un socket Unix ont été rejetées au motif qu’il s’agit d’une fonctionnalité extrêmement de niche
    Ce n’est pas implémenté pour des raisons de sécurité. Du moins pour les sockets Unix bruts ; d’autres ports limités à WebSocket ou HTTP sont possibles

    • Pour répondre brièvement sur la sécurité, les discussions que j’ai vues sur plusieurs forums Mozilla ressemblaient à ceci
      On ne peut pas autoriser le navigateur à se connecter à n’importe quel socket. Beaucoup de sockets ne souhaitent explicitement pas de connexions depuis un navigateur, ou ne sont même pas conçus en tenant compte du fait qu’un navigateur pourrait s’y connecter
      Il faudrait donc ajouter une sorte de liste d’autorisation, ce qui rendrait la fonctionnalité trop complexe pour un cas aussi niche
      Je pense donc que le point central était bien son caractère de niche
      À noter qu’Outer Loop ajoute une liste d’autorisation : https://outerloop.sh/unix-domain-sockets/

  • J’essaie de comprendre comment Outer Shell fonctionne ici. Sur le site, la motivation est présentée ainsi
    Les apps comme Jupyter ou TensorBoard, lorsqu’elles tournent sur un serveur distant, ne sont généralement pas visibles dans un navigateur web standard. Il serait très dangereux de laisser tout Internet accéder à ces apps. À la place, elles tournent sur un port local du serveur, auquel mon ordinateur ne peut pas accéder directement
    Traditionnellement, pour y accéder, il fallait ouvrir un nouveau terminal et exécuter des commandes comme ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &, dit-il
    C’est bien ça ? En général, on n’utilise ce genre de forwarding SSH que pendant le prototypage, et au moment du déploiement on crée plutôt un site web du type myjupyternotebook.com, avec une authentification pour empêcher les autres d’y accéder, non ? L’authentification HTTP Basic n’est pas non plus une catastrophe
    Si l’on veut exposer publiquement via SSH plutôt que via HTTP, il existe aussi d’autres options, comme le placer derrière un VPN ou un tunnel
    Outer Loop est très chouette, mais je ne comprends pas bien pourquoi c’est nécessaire. J’ai l’impression de passer à côté de quelque chose, donc j’aimerais qu’on m’aide à comprendre pourquoi cela a été créé

    • Il me semble qu’il existe différents groupes parmi les gens qui utilisent des serveurs, SSH, etc.
      Je suis plutôt du côté des usages comme les expériences de deep learning, l’optimisation de kernels GPU ou le développement robotique. Un robot n’est qu’un serveur qui bouge, et dans ces cas-là on utilise explicitement un ordinateur distant
      Pour les gens de ce groupe, j’ai l’impression que cet outil paraîtra plus intuitif que le flux que tu proposes. Cela dit, je projette peut-être ma propre façon de voir
      Pour moi, cela ressemble à quelque chose de fondamental qui pourrait exister. Une sorte de système d’exploitation graphique remote-first
    • Si l’utilisateur est unique, que c’est soi-même, et que le service n’est utilisé que depuis un OS de bureau, cela ressemble à une façon d’éviter d’avoir à gérer un reverse proxy et des certificats TLS
    • Si vous forwardez beaucoup de ports avec SSH, vous pouvez aussi envisager de demander à SSH de lancer un proxy SOCKS5
      ssh -D 4711 -q -C -N user@host
      Avec ça, localhost:4711 devient un proxy SOCKS5 que vous pouvez configurer dans le navigateur
      Bien sûr, un VPN WireGuard est préférable. Surtout, SSH multiplexe sur une seule connexion TCP, donc si un paquet est perdu, tout le trafic forwardé est bloqué jusqu’à sa retransmission : c’est du head-of-line blocking
    • L’authentification HTTP Basic n’est pas sûre
    • Le cas principal où j’utilise le forwarding de ports SSH, c’est pour sauver une situation quand le réseau est cassé à cause d’une mauvaise configuration

  • L’auteur semble ne jamais avoir entendu parler de Cockpit
    Les choses qu’il décrit comme « inexistantes » ou « nouvelles » sont dans Cockpit depuis plus de dix ans. Cela inclut les connexions à des serveurs web basées sur des sockets, la séparation backend-frontend des apps serveur, et même l’idée d’une console serveur avec accès au shell
    À la question « n’est-il pas étrange que cela n’existe pas encore ? », je répondrais non. Parce que cela existe depuis longtemps

    • « Soyez bienveillant. Ne soyez pas sarcastique. Discutez avec curiosité, pas comme un interrogatoire. Supprimez les piques. »
      Sincèrement,
      La police des guidelines HN :-)
      https://news.ycombinator.com/newsguidelines.html
    • Si je ne me trompe pas, Cockpit est une UI web et n’exécute pas de code natif. C’est une différence importante
    • Je n’ai jamais entendu parler de Cockpit non plus. C’est quoi ?

  • Super article. Je vais le mettre en favori pour mes recherches
    La fonctionnalité « clickity clackity » de mon terminal [0] est attachée à la machine locale, donc dès qu’on passe en distant, l’aspect graphique disparaît
    Cela commence à changer petit à petit grâce à la relecture hors ligne [1] : une GUI native et une TUI fonctionnent ensemble pour ouvrir des possibilités comme le retour en arrière. Mais il reste beaucoup de chemin, et c’est agréable de voir d’autres personnes expérimenter sérieusement. Le terminal est un domaine largement négligé
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • Les gens habitués au terminal oublient à quel point SSH est hostile pour quelqu’un qui ne l’a pas appris à l’université
    Si cela peut abaisser la barrière à l’entrée pour de petites équipes qui gèrent un VPS sans recruter une personne dédiée à la plateforme, ce sera une réussite. Je me demande toutefois comment ils gèrent les clés et les jump hosts

  • Impressionnant. On va clairement dans la bonne direction
    La couche de séparation entre le front et le back doit être découpée au plus petit « morceau » possible
    Beaucoup de gens sarcastiques ici comprendraient s’ils « ressentaient » eux-mêmes la latence et le surcoût supplémentaires. Il n’y a pas eu assez de réflexion pour découper les données avec soin selon chaque cas d’usage
    Plus encore, dans la démo, l’app top, dont il était dit qu’elle « génère de la charge en faisant souvent bouger la configuration », aurait selon moi dû faire davantage de rendu côté client via JIT. Ainsi, l’information échangée entre le Pi et le client aurait été réduite à quelque chose comme des deltas compressés de la sortie de ps

  • Il ne faut pas faire ça. Il existe de nombreuses et très bonnes raisons de sécurité, anciennes, ainsi que des raisons d’isolation du plan de contrôle web, pour lesquelles on n’autorise pas les sockets générales dans le navigateur
    L’analogie mécanique la plus proche, c’est pourquoi les ATV à trois roues sont une mauvaise idée

    • À mon avis, ce serait acceptable sous les conditions suivantes
      Les sockets doivent être bloquées par défaut et ne s’ouvrir qu’après avoir été explicitement ajoutées à une liste d’autorisation côté serveur
      Il faut une vraie prise en compte de sudo, afin qu’il soit impossible d’atteindre des sockets root sans le mot de passe sudo. Cette fonctionnalité est importante parce que, sinon, on crée une incitation à faire tourner des backends root sur des sockets accessibles à l’utilisateur
      Plus de détails ici : https://outerloop.sh/security/