Elecciones 2026Vea quién creemos que merece su voto, según nuestros criteriosLa guía →
ESCRITO EN ESPAÑOL CLARO.
CLAY TRIBUNE.
Publicidad

El Agente SSH de VSCode instala un binario de Node en su servidor, y ese es exactamente el problema. )

Una mirada al Agente SSH de VSCode, una herramienta de edición remota que instala un binario de Node en la máquina remota y abre un WebSocket de vuelta a su editor. )

Por mitch·6 min de lectura
An illustration showing a VSCode editor window connected via SSH to a remote Linux server terminal.

La función SSH Agent de VSCode es una herramienta de edición remota que funciona instalando un binario de Node en la máquina a la que se está conectando, luego abriendo un WebSocket de vuelta a su editor para que pueda recorrer sistemas de archivos, editar archivos y generar procesos de shell. También es, como dijo un comentarista, «bananas».

El autor de la publicación describe la función como una «invasión a gran escala», un término cargado para una herramienta que ejecuta un fragmento de Bash en el lado remoto para descargar e instalar un binario de Node, luego configura una conexión WebSocket de vuelta al frente de VSCode. El autor está lo suficientemente preocupado como para advertir a los lectores que no permitan que personas editen remotamente con VSCode en servidores de desarrollo, y especialmente no durante un incidente en algo en producción.

Lo que en realidad hace el Agente SSH

La función está diseñada para admitir un flujo de trabajo donde un LLM genera código, y el agente ejecuta ese código en la máquina remota, captura errores y los envía de vuelta al LLM para una iteración adicional. El autor enmarca esto como un «antídoto semi-efectivo contra la alucinación», donde el LLM escribe el código y el agente lo ejecuta, detecta fallas y envía esas fallas de vuelta al LLM para que lo intente de nuevo.

Publicidad

Ese bucle es útil en general, pero el autor argumenta que se vuelve aún más útil cuando el bucle ocurre en una instancia de Linux limpia en lugar de en su propia computadora de desarrollo. Los LLM tienen «problemas de límites», dice la publicación, e iterarán en la configuración de su sistema con la misma alegría que en el proyecto de Git en el que está trabajando.

El problema, como lo ve el autor, es que el alcance del agente se extiende mucho más allá del código que está tratando de editar. Puede recorrer el sistema de archivos, editar archivos arbitrarios, lanzar sus propios procesos PTY de shell y persistirse, todo a través de una conexión WebSocket que permanece abierta mientras el editor se está ejecutando.

Cómo se compara con Tramp

La publicación hace una comparación directa con Tramp de Emacs, que se describe como «el antepasado espiritual de los sistemas de edición remota». Tramp funciona ejecutando comandos de shell Bourne en la conexión remota, extendiendo Emacs a ese entorno. El autor sugiere que Tramp es más simple, viviendo de los recursos del lado remoto, mientras que el enfoque de VSCode implica descargar e instalar un binario de Node.

Característica Tramp (Emacs) El Agente SSH de VSCode (
Se ejecuta en el lado remoto ( Sí, a través de comandos del shell Bourne ( Sí, a través de un fragmento de Bash (
Descarga un binario ( No ( Sí, binario de Node (
Abre un WebSocket ( No ( Sí (
Puede editar archivos arbitrarios ( No ( Sí (Yes)
Puede lanzar procesos PTY de shell No (No) Sí (Yes)
Puede persistirse a sí mismo (Can persist itself) No se aborda en la fuente (Not addressed in the source) Sí (Yes)

La comparación tiene la intención de ilustrar la diferencia entre un corredor de comandos ligero y un agente a gran escala que toma el control de la máquina remota. (The comparison is meant to illustrate the difference between a lightweight command runner and a full-scale agent that takes control of the remote machine.)

Por qué le preocupa al Autor (Why the Author Is Concerned)

La preocupación expresada por el autor es sencilla: no quiere que este proceso de desarrollo iterativo ocurra en su computadora portátil de desarrollo, porque los LLM tienen problemas de límites. En una instancia de Linux limpia que se inicia instantáneamente y no puede perjudicarlo de ninguna manera, el ciclo tiene sentido. En un servidor de producción durante un incidente, no lo tiene. (The author’s stated concern is straightforward: you don’t want this iterative development process happening on your development laptop, because LLMs have boundary issues. On a clean-slate Linux instance that spins up instantly and can’t screw you over in any way, the loop makes sense. On a production server during an incident, it doesn’t.)

La publicación no menciona el nombre de la categoría de seguridad a la que pertenece, diciendo solo que el nombre es «de naturaleza murid». El autor elige no decirlo en voz alta porque eso no sería justo para VSCode. (The post stops short of naming the security category this falls into, saying only that the name is «murid in nature.» The author chooses not to say it out loud because that’s not fair to VSCode.)

«Resulta que no tenemos que preocuparnos por nada de esto para obtener una conexión personalizada a una Máquina Fly en VSCode, por lo que nada de esto importa de ninguna manera profunda, pero: hemos decidido volver a ser un blog, así que: tuvimos que aprender esto, y ahora tú también.» («It turns out we don’t have to care about any of this to get a custom connection to a Fly Machine working in VSCode, so none of this matters in any kind of deep way, but: we’ve decided to just be a blog again, so: we had to learn this, and now you do too.»)

El autor concluye señalando que no necesitan preocuparse por la función para que una Fly Machine funcione. Pero la advertencia permanece: el alcance del agente es amplio, y la máquina a la que llega es la suya.

Lo que esto significa para los usuarios

Para los desarrolladores que usan VSCode para la edición remota, la conclusión práctica es simple: sepan a qué se están conectando. La función SSH Agent es potente, pero el poder conlleva riesgos. Un LLM que puede escribir código y un agente que puede ejecutarlo y persistirse en una máquina remota es una combinación que podría fácilmente salir mal si la máquina no está debidamente aislada.

El consejo del autor es evitar que la gente edite de forma remota en VSCode en servidores de desarrollo, y ser especialmente cautelosos durante incidentes en sistemas de producción. La función es útil, pero exige una gestión cuidadosa del entorno en el que se ejecuta.

La línea final de la publicación es un irónico reconocimiento de que el tema ha sido cubierto y la lección aprendida. El autor tuvo que aprender sobre el SSH Agent para configurar una conexión de Fly Machine, y ahora está transmitiendo ese conocimiento. Para cualquiera que esté configurando la edición remota, la lección está clara: el agente es potente, pero es una locura.

Material fuente: “El SSH Agent de VSCode es una locura (2025),” fly.io.

El Cuaderno

Recibe El Cuaderno.

Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.

Enviamos una nota para confirmar. Cada número trae un enlace para darte de baja con un clic.

Publicidad

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Como Afiliado de Amazon, Clay Tribune obtiene ingresos por las compras adscritas que cumplen los requisitos aplicables.