El SSH Agent de VSCode es ridículo

• VSCode y la edición remota

  • VSCode tiene una función que permite la edición remota mediante SSH.
  • Muchos usuarios usan VSCode y LLM (modelos de lenguaje grandes) para generar código.
  • Cuando un LLM genera código incorrecto, a eso se le llama una "alucinación", y para resolverlo es importante cerrar el ciclo entre el LLM y el entorno de ejecución mediante una configuración de "agente".
  • Este proceso funciona de forma iterativa: el LLM genera código, el agente lo ejecuta, produce errores y luego esos errores se retroalimentan al LLM para repetir el ciclo.

• Problemas en el entorno de desarrollo

  • No es deseable que este proceso de desarrollo iterativo ocurra en la laptop del desarrollador.
  • Como el LLM también puede afectar la configuración del sistema, conviene realizar este trabajo en una instancia limpia de Linux.

• Emacs y Tramp

  • Emacs admite un sistema de edición remota mediante un útil paquete de Elisp llamado Tramp.
  • Tramp puede conectarse, a través de una sesión SSH, a un entorno interactivo capaz de ejecutar comandos del shell Bourne.

• El enfoque de VSCode

  • VSCode tiene una función similar a Tramp, pero a diferencia de Tramp, intenta una intrusión mucho más amplia en la conexión remota.
  • Ejecuta un stager de fragmentos de Bash para descargar un agente, incluyendo la instalación de binarios de Node.
  • El agente se ejecuta a través de SSH con port forwarding y se conecta al frontend de VSCode mediante una conexión WebSockets.
  • El protocolo base de esta conexión puede explorar el sistema de archivos, editar archivos arbitrarios, iniciar su propio proceso shell PTY y mantener persistencia.

• Preocupaciones de seguridad

  • Usar indiscriminadamente VSCode para edición remota en un servidor de desarrollo puede causar problemas para proteger información sensible o la infraestructura.
  • En particular, existe la preocupación de que usar la edición remota de VSCode cuando ocurre un problema en un entorno real de producción es extremadamente riesgoso.

• Conclusión

  • Internamente, en Fly.io, no es estrictamente necesario un agente complejo de este tipo para conectar directamente Fly Machine y VSCode.
  • Sin embargo, por motivos del blog, investigaron el método de conexión remota de VSCode, y durante esa investigación descubrieron los hechos anteriores.

[GN⁺]

Comentarios de Hacker News

• Llevaba un mes intentando escribir un texto largo sobre software. A Kurt le preocupa no estar escribiendo en el blog. Decidió escribir algo simple. Parecía que podría hacerlo en 30 minutos

  • Escribió brevemente sobre el software con el que estaban trabajando

• Cuanto más entiendes cómo funciona VSCode, más parece que se mantiene con parches temporales. Tan solo la extensión de SSH ya hace que los URI del workspace tengan dos formatos

  • Hay nombres de host y documentos JSON codificados en hexadecimal
  • Si el nombre del host incluye mayúsculas, se necesita información adicional
  • La conexión SSH puede configurar extensiones para instalar en el servidor. Pero si instalas demasiadas, no puedes conectarte a un host Windows

• No entiendo el problema de seguridad. Si puedes entrar a una máquina por SSH y hacer port forwarding de sockets, también puedes hacer otras cosas

  • Me pregunto si el problema es que alguien en la misma red puede conectarse a un puerto reenviado sin usar SSH
  • Como usuario, me gusta que el sistema SSH de VSCode funcione bien

• Opero un servidor de red y un gran problema es que los estudiantes no entienden el cliente OpenSSH

  • Les aviso a los estudiantes que no usen el plugin de servidor remoto de VSCode
  • Los estudiantes que muestran más de 100MB de uso de disco son todos usuarios de VSCode
  • Configuré el límite de procesos por usuario en 45. Si los estudiantes ignoran la advertencia, chocan con el límite
  • Uso un script que mata los procesos de .vscode-server cada 10 segundos

• La función de edición por SSH de VSCode funciona bien. Ya no necesito usar vim, nano o micro en la máquina remota

  • El agente no estorba, así que trabajar se vuelve más fácil
  • Puede haber riesgos de seguridad, pero la experiencia de desarrollo es excelente

• Aprendí que es posible la ejecución remota de código. La confianza equivocada en las herramientas de desarrollo a menudo lleva al arrepentimiento

  • SSH es una solución de los 90. Es Telnet con algunas funciones añadidas
  • Muchas cosas implementadas sobre SSH son ineficientes
  • No construimos las herramientas adecuadas. Solo seguimos agregando más funciones a las herramientas existentes

• El término "SSH agent" es confuso. Normalmente significa un demonio que cachea tokens de autenticación

• La gente que recomienda sshfs no entiende las ventajas del entorno VSCode SSH Remote

  • Puedes ejecutar todo el entorno de desarrollo de forma remota como si fuera local
  • Puede convertir una máquina vieja o un thin client en una estación de trabajo completa
  • En el marketplace de VSCode hay muchos plugins que son una amenaza de seguridad. SSH Remote o VS Tunnel no lo son

• Me incomoda permitir la edición remota de VSCode en un servidor de desarrollo. En un servidor de producción, todavía más

  • Usar VSCode Remote en un servidor de producción es una locura
  • Las demás funciones son comportamientos esperados

• La instancia local de VSCode se convierte en un thin client, y la instancia remota maneja el trabajo pesado

  • Es ideal cuando te conectas por SSH desde una laptop pequeña a una workstation potente
  • Si te conectas por SSH desde una workstation potente a una VM/VPS pequeña, recomiendo usar sshfs u otra configuración de montaje de sistema de archivos remoto