O SSH Agent do VSCode é absurda

 (fly.io)
1 pontos por GN⁺ 2025-02-09 | 1 comentários | Compartilhar no WhatsApp

  • VSCode e edição remota

    • O VSCode tem um recurso que oferece suporte à edição remota via SSH.
    • Muitos usuários estão usando VSCode e LLMs (modelos de linguagem de grande porte) para gerar código.
    • Quando um LLM gera código incorreto, isso é chamado de "alucinação", e para resolver isso é importante fechar o loop entre o LLM e o ambiente de execução por meio da configuração de um "agente".
    • Esse processo funciona de forma que o LLM gera o código, o agente executa o código, produz erros, e esses erros são enviados de volta ao LLM como feedback, repetindo o ciclo.

  • Problemas no ambiente de desenvolvimento

    • Não é desejável que esse processo iterativo de desenvolvimento aconteça no notebook do desenvolvedor.
    • Como o LLM também pode afetar a configuração do sistema, é melhor realizar esse tipo de trabalho em uma instância Linux limpa.

  • Emacs e Tramp

    • O Emacs oferece suporte a um sistema de edição remota por meio de um útil pacote Elisp chamado Tramp.
    • O Tramp pode se conectar, por uma sessão SSH, a um ambiente interativo capaz de executar comandos do shell Bourne.

  • A abordagem do VSCode

    • O VSCode tem uma funcionalidade semelhante à do Tramp, mas, ao contrário do Tramp, tenta uma intrusão mais ampla na conexão remota.
    • Ele executa um stager de snippets Bash para baixar um agente, incluindo a instalação de binários do Node.
    • O agente é executado por meio de SSH com encaminhamento de portas e se conecta ao frontend do VSCode por uma conexão WebSockets.
    • O protocolo básico dessa conexão pode navegar pelo sistema de arquivos, editar arquivos arbitrários, iniciar seus próprios processos de shell PTY e manter persistência.

  • Preocupações de segurança

    • Usar indiscriminadamente o VSCode em um servidor de desenvolvimento para edição remota pode causar problemas para proteger informações sensíveis ou a infraestrutura.
    • Há preocupação, em especial, de que usar a edição remota do VSCode quando ocorre um problema em um ambiente de produção real é extremamente arriscado.

  • Conclusão

    • Internamente, na Fly.io, um agente complexo desse tipo não é necessariamente indispensável para conectar diretamente Fly Machines e VSCode.
    • No entanto, por motivos de blog, acabaram investigando o método de conexão remota do VSCode, e no processo descobriram os fatos acima.

Leituras relacionadas

1 comentários

 
GN⁺ 2025-02-09
Comentários do Hacker News

  • Eu estava tentando escrever um texto longo sobre software há um mês. Kurt está preocupado porque não escreve no blog. Decidi escrever algo simples. Achei que conseguiria em 30 minutos

    • Escrevi de forma simples sobre o software com que estávamos lidando

  • Quanto mais entendo como o VSCode funciona, mais parece que ele é mantido com gambiarra. Só de olhar a extensão SSH, o URI do workspace tem dois formatos

    • Há nome de host e um documento JSON codificado em hexadecimal
    • Se o nome do host inclui letras maiúsculas, são necessárias informações adicionais
    • A conexão SSH permite configurar extensões para instalar no servidor. Mas, se instalar muitas, não é possível conectar a um host Windows

  • Não consigo entender o problema de segurança. Se você consegue acessar uma máquina por SSH e encaminhar sockets, também pode fazer outras coisas

    • Fico me perguntando se o problema é que alguém na mesma rede consegue se conectar à porta encaminhada sem SSH
    • Como usuário, gosto que o sistema SSH do VSCode funcione bem

  • Eu administro um servidor de rede, e um grande problema é que os estudantes não entendem o cliente OpenSSH

    • Aviso aos estudantes para não usarem o plugin de servidor remoto do VSCode
    • Dá para ver que todos os estudantes com uso de disco acima de 100MB são usuários de VSCode
    • Defini o limite de processos de usuário em 45. Se os estudantes ignorarem o aviso, acabam atingindo o limite de processos
    • Uso um script que encerra processos .vscode-server a cada 10 segundos

  • O recurso de edição via SSH do VSCode funciona bem. Passei a não usar vim, nano e micro na máquina remota

    • O agente não atrapalha, então trabalhar fica mais fácil
    • Pode haver risco de segurança, mas a experiência de desenvolvimento é excelente

  • Aprendi que é possível executar código remotamente. Confiar demais em ferramentas de desenvolvimento muitas vezes leva a arrependimento

    • SSH é uma solução dos anos 90. É telnet com alguns recursos a mais
    • Muitas coisas implementadas via SSH são ineficientes
    • Não criamos as ferramentas adequadas. Fomos apenas adicionando mais recursos às ferramentas existentes

  • O termo "agente SSH" é confuso. Normalmente significa um daemon que faz cache de tokens de autenticação

  • Quem recomenda sshfs não entende as vantagens do ambiente VSCode SSH Remote

    • É possível executar todo o ambiente de desenvolvimento remotamente como se fosse local
    • Dá para transformar máquinas antigas ou thin clients em workstations completas
    • No marketplace do VSCode há muitos plugins que são uma ameaça à segurança. SSH Remote ou VS Tunnel não são

  • Permitir edição remota do VSCode em um servidor de desenvolvimento me deixa desconfortável. Em um servidor de produção, mais ainda

    • Usar VSCode remoto em um servidor de produção é coisa de louco
    • Os outros recursos são funcionalidades esperadas

  • A instância local do VSCode vira um thin client, e a instância remota lida com o trabalho pesado

    • É adequado quando se faz SSH de um notebook pequeno para uma workstation poderosa
    • Quando se faz SSH de uma workstation poderosa para uma VM/VPS pequena, recomendo sshfs ou outra configuração de montagem de sistema de arquivos remoto