El agente SSH de VSCode es una locura (2025)
La función Remote-SSH de VS Code es elogiada por muchos desarrolladores por permitir un desarrollo remoto fluido, pero también plantea serias preocupaciones de seguridad y uso de recursos. Al instalar un agente sustancial del lado del servidor, basado en Node, que puede tanto manipular el sistema remoto como, mediante un protocolo bidireccional, potencialmente ejecutar código en la máquina local, difumina los límites de confianza esperados y amplía la superficie de ataque, especialmente cuando se usa en servidores de producción o con código no confiable. Los comentaristas comparan esta arquitectura con herramientas más ligeras como sshfs o Emacs TRAMP, debaten si las advertencias de Microsoft son suficientes y señalan alternativas de código abierto o contenidas en contenedores para un control más estricto.
Sentimiento general sobre VSCode Remote-SSH
- Muchos consideran que el desarrollo remoto basado en SSH de VSCode es muy productivo: buena UX con alta latencia, entornos de equipo consistentes, uso sencillo de CPU/RAM remotos y una experiencia de edición fluida.
- Otros lo detestan por estar inflado, ser opaco y contradecir la filosofía original de “editor ligero”. Algunos lo evitan por completo o cambian a neovim, JetBrains, Sublime u otros editores.
Modelo de seguridad y preocupaciones sobre “reverse shell”
- La preocupación central: el servidor/agente de VSCode en el host remoto puede ejecutar código en la máquina local a través de su protocolo, actuando en la práctica como un Remote Access Trojan si el remoto está comprometido.
- La propia nota de seguridad de Microsoft advierte explícitamente que un remoto comprometido puede ejecutar código localmente.
- Algunos sostienen que esto es aceptable y esperable para una “caja de desarrollo remota” en la que confías plenamente; otros lo ven como una violación del límite intuitivo de confianza unidireccional de las shells SSH.
Entornos de producción frente a desarrollo
- Hay una fuerte oposición a instalar agentes remotos de VSCode en servidores de producción; se describe como ampliar la superficie de ataque y parecerse a un rootkit/RAT.
- Algunos dicen que el verdadero problema es que las organizaciones den acceso SSH/VSCode a producción en primer lugar; VSCode no puede “policiarlo”.
- Unos pocos administradores consideran prohibir por completo VSCode remoto en sus servidores.
Uso de recursos y puntos de dolor para administradores
- Quejas sobre enormes árboles
.vscode-server(gigabytes), muchas versiones obsoletas y runtimes de Node volcados en los destinos. - En máquinas con poca RAM o poco disco (por ejemplo, Raspberry Pi, VPS de 512 MB), el servidor de VSCode puede agotar los recursos y tumbar el sistema.
- Problemas administrativos: muchas sesiones SSH persistentes, sin visibilidad del MOTD, límites de procesos alcanzados, modos de fallo opacos y sin soporte BSD.
Alternativas y comparaciones arquitectónicas
- Se compara con Emacs TRAMP y tramp‑rpc: TRAMP usa solo SSH + shell, es más seguro pero más lento; tramp‑rpc añade un pequeño ayudante remoto para mejorar la velocidad.
- sshfs y modelos de IDE antiguos (sftp/sshfs + editor local) se ven como más simples, pero sin servidores de lenguaje ni depuradores integrados.
- Los usuarios de VSCodium dependen de forks de código abierto (por ejemplo, open-remote-ssh, zygos), pero señalan lagunas en extensiones y que algunas alternativas incorporan su propio cliente SSH.
Agentes LLM y expectativas de aislamiento
- Varios participantes usan máquinas remotas como “sandboxes de LLM” y asumían que VSCode sobre SSH preservaba ese aislamiento.
- El hilo enfatiza que, con VSCode remote, una sandbox comprometida (o un agente LLM ejecutándose allí) puede pivotar de vuelta a la máquina de desarrollo local, socavando ese modelo.