Shell gráfico nativo para SSH

 (probablymarcus.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Em vez de expor apenas um terminal, servidores e dispositivos de borda podem oferecer um shell gráfico baseado em navegador, permitindo usar apps remotos de forma mais natural a partir de outros dispositivos
  • Esse shell fornece uma tela inicial de apps e uma API de descoberta de URLs entre apps, criando um fluxo para encaminhar arquivos ou recursos ao app apropriado
  • Os apps fornecem a UI por meio de pequenos servidores HTTP, mas funcionam como servidores privados voltados principalmente para SSH ou acesso local, e não como servidores web públicos em geral
  • A criptografia não precisa ser implementada por cada app individualmente, podendo ficar a cargo da camada SSH, o que permite que cada servidor de app mantenha uma estrutura simples e com poucas dependências
  • Para isso, Lewis transformou o Outer Loop em um navegador SSH e lançou o Outer Shell como open source, considerando tanto apps HTML quanto apps nativos em outerframe

Shell gráfico rodando sobre SSH

  • O navegador web já é um exemplo bem estabelecido de fluxo em que um dispositivo, o servidor, fornece a experiência para outro dispositivo, o cliente
  • Aplicando a mesma abordagem a servidores e dispositivos de borda, passa a ser possível usar apps gráficos em ambientes remotos em vez de apps baseados em terminal
  • O shell fornece uma tela inicial para os apps, e cada app serve sua interface web por meio de um pequeno servidor HTTP
  • A API do shell permite que os apps descubram as URLs uns dos outros, criando conexões entre apps
    • Por exemplo, se um app se registrar como editor de texto, outro app poderá abrir um arquivo de texto nesse app de edição ao dar duplo clique
  • Os apps podem ser web apps HTML já existentes ou apps nativos em outerframe

Como funciona a implementação e os projetos publicados

  • Os servidores HTTP dos apps normalmente funcionam como servidores privados que não podem ser acessados por outros dispositivos da rede
    • O usuário os utiliza via SSH ou localmente
    • Ao contrário da maioria das ferramentas de servidor web existentes, eles usam principalmente arquivos Unix domain socket em vez de portas localhost
    • Arquivos Unix domain socket são parecidos com portas, mas existem no sistema de arquivos e têm permissões de usuário explícitas
  • Cada servidor HTTP não precisa lidar diretamente com criptografia
    • A criptografia é tratada pela camada SSH
    • Graças a isso, cada servidor de app pode ser extremamente simples e sem dependências
  • O Outer Loop foi criado como um navegador SSH para esse shell gráfico
  • O Outer Shell open source foi lançado
  • A documentação relacionada é fornecida em três frentes
  • Em navegadores, recursos como conexão com Unix socket eram tratados como funcionalidades muito de nicho, mas ao se combinar com recursos como reconhecimento de SSH e sudo, surgem novas possibilidades técnicas
  • Web apps do tipo servidor individual, como Jupyter e Tensorboard, surgiram, mas como cada um usa protocolos de segurança pontuais, nunca se consolidou uma forma comum de encaminhá-los “corretamente”
  • Com a IA podendo ajudar na escrita de código, tornou-se prático que cada app tenha uma base de código para cada plataforma-alvo, e propõe-se como uma arquitetura web natural usar HTML para leitura e apps leves, e apps nativos adaptados à plataforma para apps de trabalho

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • É bem frustrante ver tantas reações diminuindo essa ideia. Parece que muitos leitores do HN ainda estão presos à supremacia do TUI e não têm muito interesse em GUI
    Há dois pontos centrais. TUI não é inerentemente superior a GUI, e o SSH, como camada de transporte, deveria suportar não só o encaminhamento de pty, isto é, a camada de apresentação de TUI, mas também a camada de apresentação de GUI
    Na verdade, essas duas coisas já existiam no UNIX há 30 anos, e havia também o protocolo X e a solução ssh -X. Mas o X não venceu, e o futuro em que você acessa uma máquina remota com ssh -X, executa gnome-control-center e uma janela de configurações aparece para você configurar o computador remoto nunca chegou. Se acha que chegou, é só testar: a experiência é terrível
    Mesmo assim, essa necessidade continuou existindo, e apps como o Jupyter Notebook começaram a ser desenvolvidos no formato de servidor web. O formato de documento da web, o styling e a linguagem de script do cliente acabaram se tornando, apesar de todos os defeitos, utilizáveis como camada de apresentação para apps interativos e, como partiram desde o início da ideia de documentos remotos, já trazem transparência de rede embutida
    Quando se olha para apps Electron, faz sentido reconhecer que a stack HTML/CSS/JS passou a ocupar uma posição dominante também nos apps de desktop e usá-la como camada de apresentação para apps remotos via SSH. Este projeto parece seguir essa linha
    Apps Electron também separam servidor de apresentação e cliente, como no X, chamando-os de “renderer process” e “main process”, e eles se comunicam via IPC. Em teoria, se houvesse um meio adequado de transporte para esse IPC, daria até para executar o main process e o renderer process em máquinas diferentes, e isso não parece muito diferente desta ideia

    • Também existem Thinlinc, NoMachine e X2Go, e todos usam SSH como backend principal. É uma ideia bem comum
    • ssh -X funciona bem dependendo do toolkit usado e da distância/latência. Por exemplo, Gtk não é bom por causa do pipeline de renderização
      Quando a distância e a latência ficam grandes o bastante, é preciso pensar em como isso vai parecer para o usuário. Não dá para escapar dos limites físicos, independentemente do meio. Qualquer ferramenta que prometa acesso gráfico remoto precisa ser projetada com latência em mente. O motivo de o vim funcionar bem mesmo com latência é, na prática, porque ele envia os comandos enfileirados
    • Dá para usar Wayland sobre SSH, como no X forwarding, e isso se chama waypipe. Então esse futuro não está morto
    • Pessoalmente, fico feliz que o futuro em que se abre o gnome-control-center de uma máquina remota com ssh -X para configurar um servidor não tenha chegado. Configurar servidor por GUI é um jeito abominável de fazer isso, e espero que continue restrito ao mundo Windows
    • Também é bastante irritante que o primeiro comentário seja sempre para atacar os outros comentaristas e diminuir o que eles pensam

  • Isso parece mais uma daquelas soluções em busca de um problema, algo que já apareceu muitas vezes no passado. A citação abaixo parece combinar bem com essa tentativa
    “Quem não entende Unix está condenado a reinventá-lo de forma ruim.” ~Henry Spencer

    • Contratei um programador, dei a ele um notebook Linux e pedi que fizesse algumas configurações; algumas horas depois, ele perguntou onde podia baixar o PuTTY. Foi aí que percebi que havia deixado passar algo muito importante na entrevista
    • Não é bem assim. Agora que mais gente usa Linux, as decisões de experiência do usuário tomadas 40 anos atrás estão sendo mais questionadas
      Quase toda máquina voltada a desenvolvedores tem um servidor SSH instalado e acessível
      Por que um terminal SSH tem que parecer um lixo só de texto dos anos 1960? Por que TUI deveria ser o melhor alvo possível para enviar coisas por SSH? Por que não dá para assistir a filmes em 4K no terminal ou navegar na web com pinch zoom?
    • Acho uma avaliação um pouco dura. De fato existe uma lacuna de usabilidade, e este projeto é uma tentativa de mexer nisso
      A ideia de ver diretórios Linux por SSH com componentes nativos de UI parece boa
      Embora parte disso também pareça um problema já resolvido por outros meios, como montagem com sshfs
    • A parte de “quem não entende Unix” é justamente o verdadeiro problema de fundo aqui
      Isso me lembra um texto antigo sobre termostatos programáveis. Eles eram poderosos o bastante para permitir configurações muito profundas, mas horríveis de usar para a maioria das pessoas. A ideia central era algo como: “as pessoas não querem aprender seu sistema obscuro; elas querem o benefício que ele promete”. Uma boa UI precisa saber reduzir essa distância
    • Isso parece mais próximo de Plan 9 do que de UNIX. Não é preciso tratar UNIX como algo sagrado

  • A ideia de separar frontend e backend de apps gráficos é boa. Mas é difícil dizer que isso é novidade; talvez eu esteja deixando passar alguma coisa
    Parece desconhecimento de X11Forwarding yes ou de html5 web app
    Coisas como a capacidade de um navegador se conectar a sockets Unix vêm sendo rejeitadas por serem funcionalidades extremamente de nicho
    Isso não foi implementado por questões de segurança. Pelo menos no caso de sockets Unix brutos; outras portas restritas a WebSocket ou HTTP são possíveis

    • Para responder brevemente sobre segurança, a discussão que vi em vários fóruns da Mozilla era mais ou menos esta
      Não dá para permitir que o navegador se conecte a qualquer socket. Muitos sockets explicitamente não querem conexões vindas do navegador, ou sequer levam em conta a possibilidade de um navegador conseguir se conectar a eles
      Então seria preciso adicionar algum tipo de lista de permissões, e isso tornaria a coisa complexa demais para uma funcionalidade tão de nicho
      Então, no fim, o ponto principal era mesmo o caráter de nicho
      Como referência, o Outer Loop adiciona uma lista de permissões: https://outerloop.sh/unix-domain-sockets/

  • Estou tentando entender como o Outer Shell funciona aqui. No site, a motivação é apresentada assim
    Apps como Jupyter ou TensorBoard, quando estão rodando em um servidor remoto, normalmente não ficam visíveis em um navegador web padrão. Isso porque deixar a internet inteira acessar esses apps é muito perigoso. Em vez disso, eles rodam em portas locais do servidor, e meu computador não consegue acessá-las diretamente
    Tradicionalmente, para acessar isso, era preciso abrir um novo terminal e executar comandos como ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com &
    Isso procede? Normalmente esse tipo de encaminhamento SSH é usado só na prototipagem, e na hora de implantar você não cria um site como myjupyternotebook.com com autenticação para impedir o acesso de outras pessoas? Nem autenticação básica HTTP é um grande problema
    Se a ideia é expor isso via SSH em vez de HTTP, também existem outras opções, como colocar atrás de uma VPN ou de um túnel
    O Outer Loop é muito legal, mas não entendo bem por que ele é necessário. Parece que estou deixando passar alguma coisa, então gostaria de ajuda para entender por que isso foi criado

    • Parece haver grupos diferentes entre as pessoas que usam servidores, SSH etc.
      Eu estou mais próximo dos casos de uso de experimentos de deep learning, otimização de kernel de GPU e desenvolvimento de robótica. Um robô é só um servidor que se move, e nesses casos estamos explicitamente usando um computador remoto
      Para as pessoas desse grupo, acho que essa ferramenta parece mais intuitiva do que o fluxo proposto. Mas talvez eu esteja só projetando minha própria visão
      Para mim, isso parece uma daquelas coisas fundamentais que podem existir. Dá uma sensação de sistema operacional gráfico com prioridade ao remoto
    • Se o usuário é só um, e esse usuário é você mesmo, e o serviço só será acessado a partir de um sistema operacional de desktop, isso parece poupar o trabalho de lidar com proxy reverso e certificados TLS
    • Se você está encaminhando muitas portas com SSH, também vale considerar a opção de fazer o SSH iniciar um proxy SOCKS5
      ssh -D 4711 -q -C -N user@host
      Isso faz com que localhost:4711 vire um proxy SOCKS5 que pode ser configurado no navegador
      Claro, uma VPN com WireGuard é melhor. Acima de tudo, o SSH multiplexa sobre uma única conexão TCP, então, se um pacote se perde, todo o tráfego encaminhado sofre bloqueio de cabeça de fila até a retransmissão
    • Autenticação básica HTTP não é segura
    • O principal caso em que uso encaminhamento de porta por SSH é para resgatar situações em que a rede quebrou por algum erro de configuração

  • Parece que o autor nunca ouviu falar do Cockpit
    Tudo o que ele diz que “não existe” ou é “novo” já está no Cockpit há mais de 10 anos. Isso inclui conexões de servidor web baseadas em socket, a separação entre backend e frontend de apps de servidor, e até a ideia de um console de servidor com acesso a shell
    Para a pergunta “não é estranho isso ainda não existir?”, eu responderia que não. Já existe há muito tempo

    • “Seja gentil. Não seja grosseiro. Não pressione demais; converse com curiosidade. Remova o sarcasmo.”
      Com sinceridade,
      a polícia das diretrizes do HN :-)
      https://news.ycombinator.com/newsguidelines.html
    • Se não me engano, o Cockpit é uma UI web e não executa código nativo. Essa é uma diferença importante
    • Eu também nunca ouvi falar de Cockpit. O que é isso?

  • Texto excelente. Vou deixar salvo nos favoritos para a minha pesquisa
    A funcionalidade “clickity clackity” do meu terminal [0] está presa à máquina local, então, no momento em que vou para o remoto, a parte gráfica desaparece
    Isso está mudando aos poucos graças ao replay offline [1]. GUIs nativas e TUIs funcionando juntas de uma forma que abre espaço para recursos como rebobinar. Mas ainda há um bom caminho pela frente, e é bom ver outras pessoas experimentando isso de verdade. Terminais são uma área amplamente negligenciada
    [0] https://terminal.click
    [1] https://terminal.click/posts/2026/06/tui-stability/#:~:text=...

  • As pessoas acostumadas com terminal esquecem o quanto o SSH é hostil para quem não aprendeu isso na universidade
    Se isso puder reduzir a barreira de entrada para uma equipe pequena que administra VPS sem contratar alguém de plataforma, já é um sucesso. Mas fico curioso sobre como eles lidam com chaves e hosts de salto

  • Impressionante. Definitivamente está indo na direção certa
    A camada de separação entre a frente e o fundo precisa ser cortada no menor “pedaço” possível
    Muita gente sarcástica aqui entenderia se “sentisse” por conta própria a latência e a sobrecarga extra. Não houve reflexão suficiente sobre como recortar os dados com cuidado para cada caso de uso
    Indo além, no demo, o app top, que foi usado para “mexer nas configurações com frequência e gerar carga”, na minha opinião deveria ter feito mais renderização JIT do lado do cliente. Assim, a informação trocada entre o Pi e o cliente teria sido reduzida a algo como um delta compactado da saída de ps

  • Isso não deveria ser feito. Há muitos bons motivos históricos de segurança para não dar permissões gerais de socket ao navegador, além de motivos de isolamento do plano de controle da web
    A analogia mecanicamente mais próxima é por que um ATV de 3 rodas é uma má ideia

    • Acho que ficaria aceitável sob as seguintes condições
      Os sockets deveriam ser bloqueados por padrão e só poder ser abertos depois de serem explicitamente incluídos em uma lista de permissões no lado do servidor
      Deveria haver uma noção real de sudo, de modo que não fosse possível alcançar sockets de root sem a senha do sudo. Isso é importante porque, caso contrário, cria-se um incentivo para as pessoas executarem backends como root em sockets acessíveis ao usuário
      Mais detalhes aqui: https://outerloop.sh/security/