Un shell gráfico nativo para SSH

 (probablymarcus.com)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Si los servidores y dispositivos edge ofrecen un shell gráfico basado en navegador en lugar de exponer solo una terminal, se pueden usar apps remotas de forma más natural desde otros dispositivos
  • Este shell ofrece una pantalla de inicio de apps y una API de consulta de URL entre apps, para crear flujos que pasen archivos o recursos a la app adecuada
  • Las apps proveen su UI con un pequeño servidor HTTP, pero no como un servidor web público convencional, sino como un servidor privado pensado principalmente para SSH o acceso local
  • El cifrado no tiene que implementarse dentro de cada app, sino que puede delegarse a la capa SSH, lo que permite que cada servidor de app mantenga una estructura simple y con pocas dependencias
  • Lewis creó Outer Loop como un navegador SSH para esto y publicó el proyecto open source Outer Shell, pensando tanto en apps HTML como en apps nativas de outerframe

Un shell gráfico que funciona sobre SSH

  • Los navegadores web ya son un ejemplo bien establecido de un flujo donde un dispositivo, el servidor, ofrece una experiencia a otro dispositivo, el cliente
  • Si se aplica el mismo enfoque a servidores y dispositivos edge, se pueden usar apps gráficas en entornos remotos en lugar de apps basadas en terminal
  • El shell ofrece una pantalla de inicio para las apps, y cada app sirve su interfaz web con un pequeño servidor HTTP
  • La API del shell permite que las apps encuentren las URL de otras apps y así crear conexiones entre ellas
    • Por ejemplo, si una app se registra como editor de texto, otra app puede abrir un archivo de texto con doble clic en ese editor
  • Las apps pueden ser web apps HTML existentes o apps nativas de outerframe

Cómo se implementa y qué proyectos se publicaron

  • El servidor HTTP de cada app funciona normalmente como un servidor privado al que otros dispositivos de la red no pueden acceder
    • El usuario lo utiliza a través de SSH o de forma local
    • A diferencia de la mayoría de las herramientas de servidor web existentes, usa principalmente archivos de socket de dominio Unix en lugar de puertos de localhost
    • Los archivos de socket de dominio Unix son similares a los puertos, pero existen en el sistema de archivos y tienen permisos de usuario explícitos
  • Cada servidor HTTP no necesita manejar el cifrado por sí mismo
    • El cifrado se maneja en la capa SSH
    • Gracias a esto, cada servidor de app puede ser muy simple y no tener dependencias
  • Outer Loop fue creado como un navegador SSH para este tipo de shell gráfico
  • Se publicó el proyecto open source Outer Shell
  • La documentación relacionada se ofrece en tres frentes
  • En el navegador, capacidades como las conexiones a sockets Unix se habían tratado como funciones muy de nicho, pero al combinarlas con funciones como reconocimiento de SSH y sudo aparecen nuevas posibilidades técnicas
  • Han surgido web apps de servidor individuales como Jupyter y Tensorboard, pero al usar cada una protocolos de seguridad ad hoc, no se consolidó una forma común de transmitirlas “correctamente”
  • Ahora que la IA puede ayudar a escribir código, se volvió práctico que cada app tenga una base de código por plataforma objetivo, y se propone como arquitectura web natural una estructura que use HTML para lectura y apps ligeras, y apps nativas adaptadas a cada plataforma para trabajo más intensivo

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Opiniones de Hacker News

  • Me resulta bastante frustrante que haya tantas reacciones que menosprecian esta idea. Muchos lectores de HN parecen seguir atrapados en el supremacismo de las TUI y no muestran mucho interés por las GUI.
    Hay dos puntos clave. Las TUI no son inherentemente superiores a las GUI, y SSH, como capa de transporte, debería admitir no solo el reenvío de pty, es decir, la capa de presentación TUI, sino también una capa de presentación GUI.
    De hecho, estas dos cosas ya se habían logrado en UNIX hace 30 años, y también existían soluciones como el protocolo X y ssh -X. Pero X no ganó, y nunca llegó el futuro en el que te conectabas a una máquina remota con ssh -X, ejecutabas gnome-control-center y aparecía una ventana de configuración para configurar la computadora remota. Si crees que sí funciona, pruébalo tú mismo: la experiencia es desastrosa.
    Aun así, esa necesidad siguió existiendo, y apps como Jupyter Notebook empezaron a desarrollarse como servidores web. El formato de documentos, el estilado y el lenguaje de scripting del cliente de la Web, pese a todos sus defectos, se volvieron lo suficientemente útiles como capa de presentación para apps interactivas; y como originalmente partían de documentos remotos, la transparencia de red ya viene incorporada.
    Si miras las apps de Electron, hay que admitir que el stack HTML/CSS/JS pasó a ocupar una posición dominante incluso en apps de escritorio, y es natural aprovecharlo como capa de presentación de apps remotas mediante SSH. Este proyecto parece ir en esa dirección.
    Las apps de Electron, como X, también separan el servidor de presentación y el cliente; los llaman “renderer process” y “main process”, respectivamente, y se comunican por IPC. En teoría, con un medio de transporte IPC adecuado, el main process y el renderer process podrían ejecutarse en máquinas distintas, y eso no parece muy diferente de esta idea.

    • También existen cosas como Thinlinc, NoMachine y X2Go, y todas usan SSH como backend principal. Es una idea bastante común.
    • ssh -X funciona bien según el toolkit que uses y la distancia/latencia. Por ejemplo, Gtk no va bien por su pipeline de renderizado.
      Cuando la distancia y la latencia crecen lo suficiente, hay que pensar en cómo se lo vas a mostrar al usuario. Porque, sin importar el medio, no se pueden evitar los límites físicos. Cualquier herramienta que prometa acceso gráfico remoto tiene que diseñarse teniendo en cuenta la latencia. El hecho de que vim funcione bien incluso con latencia se debe, en la práctica, a que encola comandos y los envía.
    • Se puede usar Wayland sobre SSH, como el reenvío de X, y se llama waypipe. Así que ese futuro no está muerto.
    • Personalmente, me alegra que no haya llegado el futuro en el que levantas gnome-control-center de una máquina remota con ssh -X para configurar un servidor. Configurar servidores con GUI es una forma detestable de hacerlo, y ojalá se quede solo en el mundo Windows.
    • También es bastante molesto que el primer comentario siempre sea una crítica a otros comentaristas y una descalificación de lo que piensan.

  • Esto parece una solución en busca de un problema, de las que ya hubo muchas en el pasado. La cita de abajo parece encajar bien con este intento:
    “Quienes no entienden Unix están condenados a reinventarlo, pobremente.” ~Henry Spencer

    • Contraté a un programador, le di una laptop con Linux y le pedí que configurara algunas cosas; unas horas después me preguntó dónde podía descargar PuTTY. Ahí me di cuenta de que había pasado por alto algo importante en la entrevista.
    • No es así. Ahora que más gente usa Linux, se están cuestionando más las decisiones de experiencia de usuario tomadas hace 40 años.
      Casi todas las máquinas destinadas a desarrolladores tienen un servidor SSH instalado y accesible.
      ¿Por qué una terminal SSH tiene que verse como basura solo de texto al estilo de los años 60? ¿Por qué las TUI tendrían que ser lo mejor que se puede enviar por SSH? ¿Por qué no se puede ver una película 4K en la terminal o navegar la Web con zoom de pellizco?
    • Me parece una evaluación algo dura. En realidad hay un vacío de usabilidad, y este proyecto es un intento de tocar ese punto.
      Ideas como ver directorios de Linux por SSH con componentes de UI nativos parecen razonables.
      Aunque algunas partes también parecen problemas ya resueltos de otras formas, como con montajes sshfs.
    • La parte de “quienes no entienden Unix” es, más bien, el verdadero problema de fondo aquí.
      Me recuerda a un viejo artículo sobre un termostato programable. Era lo bastante potente como para configurarlo con muchísima profundidad, pero para la mayoría de la gente era horrible de usar. La idea central era algo así como: “la gente no quiere aprender tu sistema esotérico; quiere los beneficios que ese sistema promete”. Una buena UI sabe minimizar esa brecha.
    • Esto parece más cercano a Plan 9 que a UNIX. No hace falta venerar tanto a UNIX.

  • La idea de separar el frontend y el backend de una app gráfica es buena. Pero cuesta verla como algo nuevo; tal vez se me esté escapando algo.
    Parece que no conocen X11Forwarding yes ni html5 web app.
    Funciones como que el navegador se conecte a un socket Unix se han rechazado por ser extremadamente de nicho.
    No se implementaron porque eso es un problema de seguridad. Al menos en el caso de sockets Unix crudos; otros puertos limitados a WebSocket o HTTP sí son posibles.

    • Para responder brevemente sobre la seguridad, las discusiones que vi en varios foros de Mozilla iban más o menos así:
      No se puede permitir que el navegador se conecte a cualquier socket. Muchos sockets explícitamente no quieren conexiones desde navegadores, o ni siquiera son conscientes de que un navegador podría conectarse.
      Por eso habría que agregar algún tipo de lista de permitidos, y entonces se vuelve demasiado complejo para una función tan de nicho.
      Así que creo que el punto central era su carácter de nicho.
      Como referencia, Outer Loop sí agrega una lista de permitidos: https://outerloop.sh/unix-domain-sockets/

  • Estoy tratando de entender cómo funciona Outer Shell aquí. En el sitio web explican la motivación así:
    Apps como Jupyter o TensorBoard, cuando se ejecutan en un servidor remoto, normalmente no son visibles en un navegador web estándar. Eso es porque sería muy riesgoso dejar que todo Internet acceda a esas apps. En cambio, se ejecutan en un puerto local del servidor, y mi computadora no puede acceder directamente a él.
    Tradicionalmente, para acceder a ellas había que abrir una terminal nueva y ejecutar comandos como ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &, según dicen.
    ¿Eso es correcto? Normalmente, ¿no se usa este tipo de reenvío SSH solo al prototipar, y al desplegar se crea un sitio web como myjupyternotebook.com y se le agrega autenticación para que otros no puedan acceder? La autenticación básica HTTP tampoco es para tanto.
    Si quieres que lo expuesto públicamente sea SSH y no HTTP, también hay otras opciones, como ponerlo detrás de una VPN o un túnel.
    Outer Loop es muy genial, pero no entiendo bien por qué es necesario. Siento que me estoy perdiendo algo, así que me gustaría que me ayudaran a entender por qué lo hicieron.

    • Creo que hay distintos grupos de personas que usan servidores, SSH, etc.
      Yo estoy más cerca de usos como experimentos de deep learning, optimización de kernels de GPU y desarrollo de robots. Un robot no es más que un servidor que se mueve, y en estos casos uno está usando explícitamente una computadora remota.
      Para las personas de este grupo, creo que esta herramienta se sentiría más intuitiva que el flujo que propones. Aunque quizá solo estoy proyectando mi propia forma de pensar.
      Para mí, esto se siente como una de esas cosas fundamentales que podrían existir. Algo así como un sistema operativo gráfico remote-first.
    • Si hay un solo usuario, y ese usuario eres tú, y el objetivo es acceder al servicio solo desde un sistema operativo de escritorio, parece que te ahorra el trabajo de lidiar con un proxy inverso y certificados TLS.
    • Si estás reenviando muchos puertos con SSH, también podrías considerar hacer que SSH inicie un proxy SOCKS5.
      ssh -D 4711 -q -C -N user@host
      Con eso, localhost:4711 se convierte en un proxy SOCKS5 que puedes configurar en el navegador.
      Claro que una VPN con WireGuard es mejor. Sobre todo porque SSH multiplexa sobre una sola conexión TCP, así que si se pierde un paquete, todo el tráfico reenviado queda bloqueado hasta que se retransmita, sufriendo bloqueo de cabecera.
    • La autenticación básica HTTP no es segura.
    • Donde más se usa el reenvío de puertos SSH es para rescatar algo cuando la red se rompió por alguna mala configuración.

  • Parece que el autor nunca ha oído hablar de Cockpit.
    Las cosas que dice que “no existen” o que son “nuevas” llevan más de 10 años en Cockpit. Eso incluye conexiones de servidor web basadas en sockets, separación backend-frontend para apps de servidor e incluso la idea de una consola de servidor con acceso a shell.
    A la pregunta “¿no es raro que esto todavía no exista?”, respondería que no. Porque ya existe desde hace mucho.

    • “Sé amable. No seas sarcástico. Conversa con curiosidad, no de forma inquisitiva. Elimina las indirectas.”
      Atentamente,
      la policía de las pautas de HN :-)
      https://news.ycombinator.com/newsguidelines.html
    • Si no me equivoco, Cockpit es una UI web y no ejecuta código nativo. Es una diferencia importante.
    • Yo tampoco había oído hablar de Cockpit. ¿Qué es?

  • Excelente artículo. Lo voy a guardar en marcadores para mi investigación.
    La funcionalidad “clickity clackity” de mi terminal [0] está atada a la máquina local, así que en cuanto entro a una remota pierde su carácter gráfico.
    Esto está cambiando poco a poco gracias a la reproducción offline [1]. Es una forma en la que las GUI nativas y las TUI trabajan juntas para habilitar funciones como rebobinar. Pero todavía falta bastante, y me alegra ver a otras personas experimentando en serio. La terminal es un área muy abandonada.
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • Quienes se sienten cómodos con la terminal olvidan lo hostil que es SSH para alguien que no lo aprendió en la universidad.
    Si esto puede bajar la barrera de entrada para que un equipo pequeño que administra VPS no tenga que contratar a alguien de plataforma, será un éxito. Aunque me da curiosidad cómo manejan las claves y los jump hosts.

  • Impresionante. Definitivamente va en la dirección correcta.
    La capa de separación entre el frontend y el backend debe cortar en el “fragmento” más pequeño posible.
    Muchas personas sarcásticas aquí lo entenderán cuando “sientan” directamente la latencia y la sobrecarga adicional. No se ha pensado lo suficiente en recortar cuidadosamente los datos según cada caso de uso.
    Es más, creo que la app top que en la demo “movía mucho la configuración para generar carga” debería haber hecho mucho más renderizado JIT del lado del cliente. Así, la información que viaja entre la Pi y el cliente se habría reducido a algo como un delta comprimido de la salida de ps.

  • Esto no debería hacerse. Hay muchas buenas y antiguas razones de seguridad, además de razones de aislamiento del plano de control web, para no permitir permisos de sockets generales en el navegador.
    La analogía mecánica más cercana es por qué los ATV de 3 ruedas fueron una mala idea.

    • Creo que estaría bien bajo estas condiciones:
      Los sockets deberían estar bloqueados por defecto y solo abrirse después de ser agregados explícitamente a una lista de permitidos del lado del servidor.
      Debería haber verdadera conciencia de sudo, de modo que no se pueda llegar a sockets root sin la contraseña de sudo. La razón por la que esta función es importante es que, de lo contrario, se crea un incentivo para que la gente ejecute backends root a través de sockets accesibles por el usuario.
      Hay más detalles aquí: https://outerloop.sh/security/