|

rcmd: el relay que reemplaza SSH para agentes de IA

En pocas palabras: rcmd es una herramienta open source creada por javimosch (dev.to, 18 de julio de 2026) que reemplaza SSH con un relay WebSocket: un daemon en el servidor corre los comandos del CLI, sin claves, puertos abiertos ni VPN, dejando que agentes de IA administren tus servidores.

Un desarrollador que firma como javimosch contó el 18 de julio de 2026 en dev.to cómo dejó de usar SSH para administrar su infraestructura y armó rcmd, una herramienta de ejecución remota de comandos sin claves, sin puertos abiertos y sin VPN. La clave para rcmd reemplazar SSH es un relay WebSocket que enruta cada comando entre tu máquina y el servidor destino.

La motivación es concreta. Corría unos cuantos VPS, un par de máquinas Proxmox y una Raspberry Pi, y cada vez que necesitaba tocar algo era el mismo ritual: clave SSH, puerto, firewall, y VPN si la máquina estaba detrás de NAT. ¿Y sus agentes de IA? No podían hacer nada de eso sin que él les pasara las claves a mano.

rcmd es una herramienta de código abierto para ejecutar comandos en servidores remotos sin configuración previa de red. Un daemon corre en el servidor destino y se conecta hacia afuera (outbound) a un relay WebSocket; vos ejecutás el CLI y el relay rutea el comando al daemon, que lo corre y te devuelve la salida. No abrís puertos entrantes ni tocás el firewall del servidor.

En 30 segundos

  • Qué es: rcmd ejecuta comandos remotos vía un relay WebSocket, sin claves SSH, sin puertos abiertos y sin VPN.
  • Cómo conecta: el daemon del servidor se conecta hacia afuera al relay, así que las máquinas detrás de NAT quedan alcanzables sin tunnel.
  • Novedades de esta semana (julio 2026): comandos programados tipo cron y port forwarding a servicios que escuchan en localhost del server.
  • Para qué sirve de verdad: darles a agentes de IA acceso acotado para administrar servidores, sin repartir la clave maestra.
  • El punto débil admitido por el autor: un token daba acceso total a todos los targets, y de ahí salió el trabajo sobre control de acceso.

¿Por qué SSH no alcanza para los agentes de IA?

SSH fue diseñado para que una persona se conecte a una máquina, no para que un proceso automático lo haga a escala. El problema práctico: para que un agente corra comandos, le tenés que entregar una clave SSH o armarle un tunnel. Cualquiera que haya administrado varios servidores sabe lo que eso significa en NAT y firewalls. Lo explicamos a fondo en automatizar tus deployments sin intervención manual.

Ponele que tenés un agente que necesita reiniciar un contenedor Docker a las 3 de la mañana en una máquina que está detrás de NAT. Con SSH clásico tenés que exponer un puerto, gestionar la rotación de la clave, y rezar para que nadie encuentre ese puerto antes que vos. Subís el agente, lo probás en local, anda bárbaro, lo mandás a producción y de repente no llega al server porque el firewall del proveedor bloquea el entrante, la IP cambió y nadie documentó qué puerto era.

rcmd invierte la dirección de la conexión. El daemon sale hacia el relay, así que el servidor nunca acepta conexiones entrantes. Eso resuelve el NAT de una y saca los puertos abiertos de la ecuación.

¿Cómo funciona la arquitectura de rcmd para reemplazar SSH?

El flujo tiene tres piezas: el cliente (vos, con el CLI), el relay WebSocket, y el daemon que corre en cada servidor destino. El daemon inicia la conexión hacia el relay; el relay actúa de intermediario y rutea lo que vos mandás.

Vos ──wss──► relay ──wss──► daemon del target (corre el comando, devuelve output)

Según la descripción del proyecto en su repositorio de GitHub, se distribuye como binario en Go de alrededor de 7 MB y guarda su estado en JSON, sin base de datos aparte. Eso lo vuelve fácil de tirar en una Raspberry Pi o en un VPS chico sin dependencias pesadas. Un binario, un archivo de estado, listo.

¿Qué funcionalidades trajo la última versión?

Lo que se publicó esta semana, según el propio autor en dev.to, son dos cosas: comandos programados (cron) y port forwarding. Las dos apuntan a reemplazar combos que hoy armás con SSH más scripts sueltos. Esto se conecta con lo que analizamos en elegir la herramienta de automatización correcta.

Comandos programados (cron)

El relay corre una goroutine de scheduler. Cuando un job se dispara, reenvía el comando al daemon del target. Si el target está offline en ese momento, la corrida se registra como “skipped” y no hay cola de reintentos: el próximo tick vuelve a intentar. El historial persiste aunque reinicies el relay. En criollo, esto reemplaza el combo de crontab más SSH más script de monitoreo con un solo comando.

Port forwarding (tunnel)

El tunnel reenvía un puerto local a una dirección remota a través del daemon del target. Sirve para llegar a una base de datos o un servicio que solo escucha en localhost del servidor remoto. Es la función que más entusiasma al autor, y se entiende: te ahorra el clásico ssh -L para pegarle a un Postgres que no querés exponer.

¿Cómo se controla qué comandos ejecuta un agente?

Acá está el problema honesto que el autor pone sobre la mesa: en el esquema simple, un token equivale a acceso total a todos los targets. Si querés que un compañero o un agente de IA corran comandos, o compartís tu token maestro (una pesadilla de seguridad, sus palabras) o armás una cuenta separada que no ve los mismos targets.

La respuesta que empezó a construir va por tokens con permisos acotados por target, en vez de la lógica de “un token, todo el reino”. El outline del proyecto habla de roles diferenciados (admin, operator, viewer), auditoría automática de cada comando ejecutado, e invitaciones por correo con códigos de acceso. Tomá los detalles finos con pinzas: el posteo original quedó cortado justo en esa parte, así que conviene confirmar los roles exactos en la documentación del repo antes de apoyar una política de seguridad en ellos. Cubrimos ese tema en detalle en infraestructura distribuida en múltiples ubicaciones.

El principio de fondo sí es claro: querés que un agente pueda reiniciar un servicio sin darle, de yapa, la llave para borrar el disco de otro servidor.

rcmd vs SSH y otras alternativas: ¿cuándo conviene cada una?

SSH sigue siendo el estándar para que una persona entre a una máquina de forma interactiva. rcmd apunta a otro nicho: automatización y agentes que necesitan acceso acotado sin abrir la superficie de red. No compiten por lo mismo, aunque se pisen en algunos casos.

HerramientaPuertos entrantesSirve para agentes IAAuditoría integradaFuerte en
SSH clásicoSí (puerto 22 o custom)Con claves compartidas, incómodoNo nativaAcceso humano interactivo
SSH-Agent forwardingRiesgoso (reenvía credenciales)No nativaSaltar entre hosts
MoshSí (UDP)NoNoConexiones con roaming e itinerancia
rcmdNo (daemon sale outbound)Sí, con tokens acotadosSí (según el proyecto)Automatización y agentes detrás de NAT
rcmd reemplazar ssh diagrama explicativo

Regla rápida: SSH para entrar vos a mano, rcmd para automatizar y para agentes, Mosh cuando te movés entre redes y la conexión se corta seguido.

Casos de uso concretos

Dos ejemplos que salen directo de lo que trae la versión. Uno: programar el reinicio de un contenedor Docker a horario en una máquina Proxmox, sin dejar el puerto SSH expuesto y sin un cron local que después nadie recuerda dónde vive. Dos: darle a un agente de IA (tipo un orquestador de deploys) un token que solo puede correr comandos en el target de staging, mientras producción queda con otro token distinto. Te puede servir nuestra cobertura de ejecutar agentes sin depender de APIs externas.

Para quien administra su propia infraestructura, el escenario típico es una mezcla de VPS y una Raspberry en casa detrás del router. Si estás montando esos VPS en Argentina, donweb.com te da el servidor y rcmd te resuelve el acceso remoto sin pelearte con el firewall entrante. El daemon sale hacia el relay y listo.

Errores comunes al empezar con rcmd

  • Confiar en un solo token para todo: el propio autor marca que un token daba acceso total. Si vas a sumar agentes o gente, esperá o configurá el control de acceso acotado; no repartas el token maestro.
  • Asumir que los jobs offline se reintentan solos: si el target está caído cuando dispara un cron, la corrida se marca como “skipped” y no hay cola de reintentos. Si un comando es crítico, agregá tu propia verificación.
  • Tratar el relay como una pieza descartable: todo el tráfico pasa por ahí. Es el punto central de tu esquema, así que dónde lo corrés y quién lo controla importa tanto como el servidor destino.
  • Dar por sentados los roles sin leer la doc: los detalles de admin/operator/viewer venían en la parte del posteo que quedó cortada. Verificá qué permite cada rol antes de armar tu política.

Preguntas Frecuentes

¿Qué es rcmd?

rcmd es una herramienta de código abierto para ejecutar comandos en servidores remotos sin claves SSH, sin puertos abiertos y sin VPN. Usa un relay WebSocket como intermediario y un daemon que corre en cada servidor y se conecta hacia afuera. La publicó javimosch en dev.to el 18 de julio de 2026.

¿Cómo reemplaza rcmd a SSH sin abrir puertos?

El daemon del servidor inicia la conexión hacia el relay (outbound), en vez de esperar conexiones entrantes. Como el servidor no acepta tráfico de entrada, no necesitás abrir el puerto 22 ni tocar el firewall, y las máquinas detrás de NAT quedan alcanzables sin tunnel ni VPN.

¿rcmd es gratis?

Sí, es un proyecto de código abierto disponible en GitHub. Se distribuye como un binario en Go de alrededor de 7 MB que guarda su estado en JSON, sin costo de licencia según lo publicado por el autor.

¿Sirve rcmd para darles acceso a agentes de IA?

Ese es justo el caso que motivó el proyecto. En vez de entregarle a un agente una clave SSH o un tunnel, le das un token, y el trabajo del autor apunta a que ese token sea acotado por target en lugar de dar acceso total. Confirmá los roles disponibles en la documentación antes de definir permisos.

¿Qué pasa si el servidor está offline cuando dispara un comando programado?

La corrida se registra como “skipped” y no entra en ninguna cola de reintentos. El próximo tick del scheduler vuelve a intentar. El historial de ejecuciones persiste aunque reinicies el relay, así que podés revisar qué se saltó.

Conclusión

rcmd no viene a jubilar a SSH para el uso interactivo de siempre. Ataca un dolor puntual que se volvió urgente con los agentes de IA: cómo dejar que un proceso automático corra comandos en tus servidores sin repartir claves ni abrir la red. La inversión de la conexión (el daemon sale hacia el relay) es la idea que hace que todo lo demás encaje, y el cron y el port forwarding de esta semana muestran hacia dónde va.

Si administrás varias máquinas y estás pensando en sumar automatización o agentes, vale la pena probarlo en un target de prueba. Eso sí: esperá a que el control de acceso acotado esté firme antes de darle un token a algo que no sea de tu confianza total, y no apoyes nada crítico en el cron sin tu propia verificación, porque no reintenta solo.

Fuentes

Te puede interesar...