Durante más de una década, mRemoteNG ha sido la discreta herramienta de cabecera de innumerables salas de servidores y equipos de IT. Si has pasado tiempo gestionando infraestructura Windows, conoces la interfaz: un árbol de carpetas a la izquierda, pestañas en la parte superior, conexiones abiertas una al lado de otra. SSH aquí, RDP allá, VNC en la pestaña siguiente, todo en una sola ventana y todo recordado entre sesiones.
Luego te pasas a Linux — y nada encaja del todo.
mRemoteNG sigue siendo solo para Windows desde que se separó de mRemote en 2010, atado a una base de código .NET / WinForms que nunca dio el salto a Linux. Hilos de Reddit, respuestas de StackOverflow, issues de GitHub y posts en foros de los últimos diez años terminan todos igual: "mRemoteNG no funciona en Linux — prueba X o Y."
La mayoría de los usuarios de Linux lo han compensado armando un flujo de trabajo a base de piezas: terminator o tmux para shells en pestañas, una configuración SSH con decenas de hosts, pestañas del navegador con consolas VNC y un gestor de contraseñas para las credenciales. Funciona. Pero también reparte un único modelo mental — "mis sesiones remotas" — entre cuatro herramientas distintas que no saben nada unas de otras.
Remota es ese mismo flujo de trabajo, construido para Linux desde el primer día.
Qué es Remota
Remota es un gestor de conexiones remotas gratuito y open source para Linux. Reúne SSH, RDP, VNC y Telnet en la misma ventana, organizados en un árbol de carpetas, con una bóveda local cifrada para las credenciales, soporte nativo para ProxyJump de SSH y un relay autoalojado para llegar a máquinas detrás de NAT. Está construido sobre Tauri v2 — un backend en Rust, una ventana nativa del sistema operativo y un binario pequeño que arranca al instante.
Por dentro es un proyecto clean-room: nada de código de mRemoteNG, ninguna dependencia de WINE ni de una máquina virtual, ningún Chromium empaquetado. El flujo de trabajo resultará familiar a cualquiera que haya pasado tiempo en mRemoteNG (ese era el objetivo), pero la implementación es completamente distinta.
Dónde mRemoteNG sigue ganando
Empecemos siendo honestos. mRemoteNG lleva más de una década en uso en producción y se ganó esa reputación:
Soporte multiprotocolo maduro — SSH vía PuTTY, RDP vía el control ActiveX de RDP de Microsoft, VNC, ICA, HTTPS, rlogin, raw sockets. Cada una de esas integraciones tiene detrás años de depuración en el mundo real.
Una gran base de usuarios y mucho conocimiento acumulado — Las respuestas de StackOverflow, los hilos de foros, los posts de blog y las guías acumulados durante años hacen que, si te has topado con un caso límite concreto, probablemente otra persona ya haya documentado la solución.
Archivos de conexión portables — El formato confCons.xml es un archivo XML plano. Puedes llevarlo en una memoria USB, sincronizarlo con Git o incluirlo en un kit de onboarding.
Pulido pensado para Windows — Integración profunda con el almacén de credenciales de Windows, rendimiento de RDP muy afinado, soporte de Kerberos y Active Directory. Si tu mundo son entornos Windows y máquinas Windows, mRemoteNG encaja de forma natural.
El problema no es que mRemoteNG sea malo. El problema es que mRemoteNG nunca llegó a Linux.
Qué aporta Remota a Linux
El objetivo de diseño era conservar el modelo mental de mRemoteNG (árbol + pestañas + carpetas + credenciales) y hacer que se sintiera nativo en Linux.
Multiprotocolo en pestañas — SSH, RDP, VNC y Telnet se abren cada uno en una pestaña de la misma ventana. Ctrl+Tab entre un shell de producción, una sesión en un jump host y un RDP de Windows.
Árbol de carpetas con arrastrar y soltar e iconos personalizados — Anida tanto como necesites. Elige un icono por carpeta o por host para que el árbol se pueda recorrer de un vistazo.
Herencia de credenciales — Define el usuario, la clave SSH o el jump host una vez en una carpeta y todos los hijos lo heredan. Sobrescríbelo en un host concreto cuando tenga que ser distinto.
Bóveda local cifrada — Las conexiones y los secretos se guardan en tu disco en una bóveda cifrada con AES-256-GCM. La clave se deriva de tu contraseña maestra con Argon2id. Nada sale de tu máquina.
Jump hosts SSH (ProxyJump nativo) — Encadena bastiones igual que lo hace OpenSSH, configurado por carpeta o por host.
NAT traversal autoalojado — Llega a máquinas detrás de CGNAT o de firewalls restrictivos mediante un pequeño agente que se conecta hacia fuera a un relay que alojas tú. Sin nube de terceros, sin vendor lock-in, sin cuenta.
Importación desde mRemoteNG — Arrastra tu confCons.xml a Remota y las carpetas, los hosts, las credenciales y los ajustes de protocolo se trasladan. No tienes que reconstruir tu mundo.
Funcionalidad por funcionalidad: mRemoteNG vs Remota
Así se comparan los dos proyectos en las capacidades que la gente realmente comprueba antes de cambiar de herramienta.
Plataforma. mRemoteNG solo funciona en Windows. Remota funciona de forma nativa en Linux (x86_64) — .deb para Debian/Ubuntu, .rpm para la familia Fedora/RHEL/openSUSE y un .AppImage portable para todo lo demás. Arm64 está en el roadmap.
SSH. Ambos lo soportan. mRemoteNG usa un PuTTY integrado. Remota usa un stack SSH moderno en Rust conectado a un pseudoterminal real que se redimensiona con la ventana — vim, k9s, htop y tmux se ven exactamente igual que en tu terminal nativo.
RDP. Ambos lo soportan. mRemoteNG usa el control ActiveX de RDP de Microsoft. La vía RDP de Remota funciona hoy para las conexiones habituales a hosts Windows y xrdp, y el equipo está puliendo activamente los casos límite.
VNC. Ambos lo soportan. mRemoteNG tiene años de madurez. La vía VNC de Remota ya es funcional (los hosts TigerVNC y TightVNC funcionan) y se sigue refinando.
Telnet. Ambos lo soportan. En Remota, Telnet comparte el mismo terminal que SSH, así que el panel se comporta igual.
Sesiones en pestañas. Ambos. El mismo modelo mental.
Árbol de carpetas. Ambos. Remota añade reorganización con arrastrar y soltar e iconos personalizados por nodo.
Herencia de credenciales. Ambos. El mismo patrón — valores por defecto en la carpeta con sobrescrituras por host.
Jump hosts SSH. Ambos. Remota lo implementa directamente como ProxyJump al estilo de OpenSSH.
Bóveda cifrada en reposo. Ambos guardan las credenciales cifradas. Remota usa AES-256-GCM con derivación de clave Argon2id, y la bóveda se desbloquea con una contraseña maestra que defines en el primer arranque.
NAT traversal. mRemoteNG no incluye ninguno — tienes que traer tu propia herramienta (AnyDesk, RustDesk, remote.it, túneles SSH inversos). Remota incluye un relay autoalojado que puedes ejecutar en tu propia infraestructura.
Importación desde mRemoteNG. Remota lee confCons.xml directamente. Por eso la migración de mRemoteNG *hacia* Remota es un trabajo de una sola vez — una única importación.
Licencia. mRemoteNG es GPLv2. Remota es AGPL-3.0-only.
Stack tecnológico. mRemoteNG es .NET / WinForms. Remota es Tauri v2 (backend en Rust, ventana nativa del sistema operativo, interfaz en WebView).
Ritmo de releases. La última release estable de mRemoteNG fue en 2023 y el proyecto está en modo de mantenimiento mínimo. Remota se desarrolla activamente con releases regulares — v0.1.2 es la build actual.
Dónde Remota va más allá de mRemoteNG
Tres capacidades que Remota añade y que mRemoteNG no tiene.
NAT traversal autoalojado, sin nube de terceros. Si la máquina a la que quieres llegar está detrás de CGNAT o de un firewall hostil, mRemoteNG no es la respuesta — tienes que recurrir a otro producto. AnyDesk, RustDesk y remote.it resuelven el problema, pero por defecto todos dependen de servidores operados por el proveedor. Si quieres ese patrón sin enviar el tráfico de tus sesiones a través de la infraestructura de otro, el relay de Remota es un reemplazo directo: instálalo en cualquier VPS o servidor on-prem, apunta el agente hacia él y el NAT traversal pasa por hardware que es tuyo. Nada sale de tu perímetro.
Nativo de Linux, no virtualizado. Ejecutar mRemoteNG en Linux hoy suele significar WINE, una VM Windows o una estación de trabajo Windows completa. Cada una de esas opciones añade latencia, fricción con el portapapeles y todo un segundo sistema operativo que mantener parcheado. Remota es un binario Tauri nativo — un proceso, una ventana nativa, una integración sensata con el escritorio Linux.
Moderno, pequeño, rápido. El agente en Rust ocupa unos 4 MB en disco. La aplicación de escritorio ocupa unos 20 MB. El arranque en frío es instantáneo. No es otro Chromium empaquetado; es una ventana nativa que, simplemente, renderiza su interfaz en un WebView.
Unas palabras honestas sobre el estado actual
Remota es un producto real, en uso diario, pero todavía no es un sustituto idéntico para cada flujo de trabajo de mRemoteNG. Así están las cosas hoy:
SSH está listo para producción. Es lo que el equipo de Privum usa a diario para gestionar su propia infraestructura. Jump hosts, autenticación por clave, PTY que se adapta al redimensionado, sesiones en pestañas — la vía SSH es sólida.
RDP, VNC y Telnet comparten la misma arquitectura, pero todavía están madurando. Conectan. Renderizan. Los casos límite de nivel enterprise — profundidades de color esotéricas, canales de portapapeles complejos, RemoteFX, RDP sobre TLS con políticas de certificados estrictas — encontrarán asperezas. Las correcciones salen con regularidad.
Si tu día a día es un 90% SSH, Remota está listo. Eso cubre a la mayoría de sysadmins de Linux, ingenieros DevOps, aficionados al homelab, estudiantes y pequeños equipos de IT.
Si necesitas paridad en RDP o VNC para trabajo intensivo con escritorios Windows, sigue las releases. La distancia se está acortando, pero de momento mantén mRemoteNG (en Windows) o tu herramienta actual en paralelo.
Aquí no hay marketing grandilocuente — ese es el estado real.
Migrar desde mRemoteNG
La migración es deliberadamente rápida.
- 1Exporta o localiza tu
confCons.xmlactual (el archivo de conexiones por defecto de mRemoteNG). - 2Instala Remota en tu estación de trabajo Linux con uno de los comandos que verás a continuación.
- 3Importa el archivo. Carpetas, hosts, protocolos, ajustes de jump host y credenciales guardadas se trasladan de una sola vez.
- 4Define tu contraseña maestra de Remota — a partir de ahora será la clave que desbloquea la bóveda local.
No estás reconstruyendo tu mundo. Lo estás trasladando.
Cómo instalarlo
Remota se distribuye como tres artefactos para Linux x86_64. Descarga la última release desde GitHub e instálala con tu gestor de paquetes, o ejecútala directamente como AppImage.
Debian / Ubuntu:
sudo apt install ./Remota_0.1.2_amd64.debFedora / RHEL / openSUSE:
sudo dnf install ./Remota-0.1.2-1.x86_64.rpmCualquier Linux x86_64 (portable):
chmod +x Remota_*.AppImage
./Remota_*.AppImageDescarga los assets de la release actual desde la página de releases de Remota en GitHub. Los nombres de los paquetes incluyen la versión — cambia 0.1.2 por el tag más reciente si ya se ha publicado una build posterior.
Prueba Remota
Gratis. Open source bajo AGPL-3.0-only. Sin cuenta. Sin nube. Sin telemetría.
- Página del producto: Remota — Gestor de conexiones remotas open source para Linux
- Código fuente: github.com/privum-cloud/remota
- Agente autoalojado: github.com/privum-cloud/remota-client
Si mRemoteNG ha sido la forma de "cómo quiero gestionar mis sesiones remotas" y Linux ha sido la plataforma que nunca lo tuvo, Remota es la versión que por fin lo ofrece.
Preguntas frecuentes
¿Remota es un fork de mRemoteNG? No. Remota es un proyecto clean-room inspirado en el flujo de trabajo de mRemoteNG — la experiencia multiprotocolo, en pestañas y organizada en carpetas con la que miles de administradores desarrollaron memoria muscular. No comparte código con mRemoteNG y usa un stack completamente distinto (Rust y Tauri en lugar de .NET y WinForms).
¿Puedo importar mis conexiones de mRemoteNG? Sí. Remota lee directamente el archivo confCons.xml de mRemoteNG. Carpetas, hosts, protocolos, ajustes de jump host y credenciales guardadas se trasladan de una sola vez.
¿Remota requiere una cuenta en la nube? No. Todo es local. Tus credenciales viven en una bóveda en disco cifrada con AES-256-GCM, que solo se desbloquea con tu contraseña maestra. El NAT traversal, cuando lo necesitas, usa un relay que alojas tú en tu propia infraestructura — no los servidores del proveedor de los que AnyDesk y RustDesk dependen por defecto.