Durante mais de uma década, o mRemoteNG foi o discreto burro de carga de inúmeras salas de servidores e equipas de TI. Se passaste algum tempo a gerir infraestrutura Windows, conheces a interface: uma árvore de pastas à esquerda, separadores em cima, ligações abertas lado a lado. SSH aqui, RDP ali, VNC no separador seguinte, tudo numa só janela e tudo lembrado entre sessões.
Depois mudas para Linux — e nada encaixa bem.
O mRemoteNG continua a ser exclusivo do Windows desde que se separou do mRemote em 2010, preso a uma base de código .NET / WinForms que nunca deu o salto para Linux. Threads no Reddit, respostas no StackOverflow, issues no GitHub e posts em fóruns ao longo dos últimos dez anos acabam todos da mesma forma: "o mRemoteNG não corre em Linux — experimenta X ou Y."
A maioria dos utilizadores de Linux compensou isto montando um fluxo de trabalho aos bocados: terminator ou tmux para shells em separadores, uma configuração SSH com dezenas de hosts, separadores do browser com consolas VNC e um gestor de palavras-passe para as credenciais. Funciona. Mas também espalha um único modelo mental — "as minhas sessões remotas" — por quatro ferramentas diferentes que não sabem nada umas das outras.
O Remota é esse mesmo fluxo de trabalho, construído para Linux desde o primeiro dia.
O que é o Remota
O Remota é um gestor de ligações remotas gratuito e open source para Linux. Junta SSH, RDP, VNC e Telnet na mesma janela, organizados numa árvore de pastas, com um cofre local cifrado para as credenciais, suporte nativo para ProxyJump do SSH e um relay autoalojado para chegar a máquinas atrás de NAT. É construído sobre Tauri v2 — um backend em Rust, uma janela nativa do sistema operativo e um binário pequeno que arranca instantaneamente.
Por dentro é um projeto clean-room: nenhum código do mRemoteNG, nenhuma dependência de WINE ou de uma máquina virtual, nenhum Chromium incluído. O fluxo de trabalho vai ser familiar a quem já passou tempo no mRemoteNG (era esse o objetivo), mas a implementação é completamente diferente.
Onde o mRemoteNG continua a ganhar
Comecemos com honestidade. O mRemoteNG está em uso em produção há mais de uma década e ganhou essa reputação:
Suporte multiprotocolo maduro — SSH via PuTTY, RDP via o controlo ActiveX de RDP da Microsoft, VNC, ICA, HTTPS, rlogin, raw sockets. Cada uma destas integrações tem por trás anos de depuração no mundo real.
Uma grande base de utilizadores e muito conhecimento acumulado — Respostas no StackOverflow, threads em fóruns, posts de blogue e guias acumulados ao longo dos anos significam que, se te deparaste com um caso limite específico, provavelmente outra pessoa já documentou a solução.
Ficheiros de ligação portáteis — O formato confCons.xml é um ficheiro XML simples. Podes levá-lo numa pen USB, sincronizá-lo com Git ou incluí-lo num kit de onboarding.
Acabamento pensado para Windows — Integração profunda com o gestor de credenciais do Windows, desempenho de RDP muito afinado, suporte para Kerberos e Active Directory. Se o teu mundo são empresas Windows e máquinas Windows, o mRemoteNG encaixa naturalmente.
O problema não é o mRemoteNG ser mau. O problema é o mRemoteNG nunca ter chegado ao Linux.
O que o Remota traz ao Linux
O objetivo de design era manter o modelo mental do mRemoteNG (árvore + separadores + pastas + credenciais) e fazê-lo parecer nativo em Linux.
Multiprotocolo em separadores — SSH, RDP, VNC e Telnet abrem cada um num separador da mesma janela. Ctrl+Tab entre uma shell de produção, uma sessão num jump host e um RDP de Windows.
Árvore de pastas com arrastar e largar e ícones personalizados — Aninha quantos níveis precisares. Escolhe um ícone por pasta ou por host para que a árvore se leia num relance.
Herança de credenciais — Define o utilizador, a chave SSH ou o jump host uma vez numa pasta e todos os filhos herdam. Sobrepõe num host específico quando tiver de ser diferente.
Cofre local cifrado — As ligações e os segredos são guardados no teu disco num cofre cifrado com AES-256-GCM. A chave é derivada da tua palavra-passe mestra com Argon2id. Nada sai da tua máquina.
Jump hosts SSH (ProxyJump nativo) — Encadeia bastiões da mesma forma que o OpenSSH, configurado por pasta ou por host.
NAT traversal autoalojado — Chega a máquinas atrás de CGNAT ou de firewalls restritivas através de um pequeno agente que liga para fora, para um relay alojado por ti. Sem cloud de terceiros, sem vendor lock-in, sem conta.
Importação a partir do mRemoteNG — Larga o teu confCons.xml no Remota e as pastas, os hosts, as credenciais e as definições de protocolo passam para o outro lado. Não tens de reconstruir o teu mundo.
Funcionalidade a funcionalidade: mRemoteNG vs Remota
Eis como os dois projetos se comparam nas capacidades que as pessoas realmente verificam antes de mudar de ferramenta.
Plataforma. O mRemoteNG só corre em Windows. O Remota corre nativamente em Linux (x86_64) — .deb para Debian/Ubuntu, .rpm para a família Fedora/RHEL/openSUSE e um .AppImage portátil para tudo o resto. Arm64 está no roadmap.
SSH. Ambos suportam. O mRemoteNG usa um PuTTY incluído. O Remota usa um stack SSH moderno em Rust ligado a um pseudoterminal real que se redimensiona com a janela — vim, k9s, htop e tmux aparecem tal como no teu terminal nativo.
RDP. Ambos suportam. O mRemoteNG usa o controlo ActiveX de RDP da Microsoft. A implementação de RDP do Remota funciona hoje para as ligações típicas a hosts Windows e xrdp, e a equipa está ativamente a polir os casos limite.
VNC. Ambos suportam. O mRemoteNG tem anos de maturidade. A implementação de VNC do Remota já é funcional (hosts TigerVNC e TightVNC funcionam) e continua a ser refinado.
Telnet. Ambos suportam. No Remota, o Telnet partilha o mesmo terminal que o SSH, por isso o painel comporta-se da mesma forma.
Sessões em separadores. Ambos. O mesmo modelo mental.
Árvore de pastas. Ambos. O Remota acrescenta reorganização com arrastar e largar e ícones personalizados por nó.
Herança de credenciais. Ambos. O mesmo padrão — predefinições na pasta com sobreposições por host.
Jump hosts SSH. Ambos. O Remota implementa-o diretamente como ProxyJump ao estilo do OpenSSH.
Cofre cifrado em repouso. Ambos guardam as credenciais cifradas. O Remota usa AES-256-GCM com derivação de chave Argon2id, e o cofre é desbloqueado por uma palavra-passe mestra que defines no primeiro arranque.
NAT traversal. O mRemoteNG não inclui nenhum — tens de trazer a tua própria ferramenta (AnyDesk, RustDesk, remote.it, túneis SSH reversos). O Remota inclui um relay autoalojado que podes correr na tua própria infraestrutura.
Importação a partir do mRemoteNG. O Remota lê o confCons.xml diretamente. É por isso que a migração do mRemoteNG *para* o Remota é um trabalho de uma só vez — uma única importação.
Licença. O mRemoteNG é GPLv2. O Remota é AGPL-3.0-only.
Stack tecnológico. O mRemoteNG é .NET / WinForms. O Remota é Tauri v2 (backend em Rust, janela nativa do sistema operativo, interface em WebView).
Cadência de releases. A release estável mais recente do mRemoteNG foi em 2023 e o projeto está em modo de manutenção mínima. O Remota é desenvolvido ativamente, com releases regulares — a v0.1.2 é a build atual.
Onde o Remota vai além do mRemoteNG
Três capacidades que o Remota acrescenta e que o mRemoteNG não tem.
NAT traversal autoalojado, sem cloud de terceiros. Se a máquina a que queres chegar está atrás de CGNAT ou de uma firewall hostil, o mRemoteNG não é a resposta — tens de recorrer a outro produto. AnyDesk, RustDesk e remote.it resolvem o problema, mas, por predefinição, todos dependem de servidores operados pelo fornecedor. Se queres esse padrão sem enviar o tráfego das sessões pela infraestrutura de outra pessoa, o relay do Remota é um substituto direto: instala-o em qualquer VPS ou servidor on-prem, aponta o agente para ele e o NAT traversal passa por hardware que é teu. Nada sai do teu perímetro.
Nativo em Linux, não virtualizado. Correr o mRemoteNG em Linux hoje significa normalmente WINE, uma VM Windows ou uma estação de trabalho Windows completa. Cada uma destas opções acrescenta latência, atrito na área de transferência e todo um segundo sistema operativo para manter atualizado. O Remota é um binário Tauri nativo — um processo, uma janela nativa, uma integração sensata com o ambiente de trabalho Linux.
Moderno, pequeno, rápido. O agente em Rust ocupa cerca de 4 MB em disco. A aplicação de desktop ocupa cerca de 20 MB. O arranque a frio é instantâneo. Não é mais um Chromium incluído; é uma janela nativa que, por acaso, desenha a interface num WebView.
Uma palavra honesta sobre o estado atual
O Remota é um produto real, em uso diário, mas ainda não é um substituto equivalente para todos os fluxos de trabalho do mRemoteNG. Eis como estão as coisas hoje:
O SSH está pronto para produção. É o que a equipa da Privum usa todos os dias para gerir a sua própria infraestrutura. Jump hosts, autenticação por chave, PTY que acompanha o redimensionamento, sessões em separadores — a implementação de SSH é sólida.
RDP, VNC e Telnet partilham a mesma arquitetura, mas ainda estão a amadurecer. Ligam-se. Mostram o ecrã remoto. Os casos limite de nível empresarial — profundidades de cor esotéricas, canais de área de transferência complexos, RemoteFX, RDP sobre TLS com políticas de certificados rigorosas — vão encontrar arestas por limar. As correções saem com regularidade.
Se o teu dia a dia é 90% SSH, o Remota está pronto. Isso cobre a maioria dos sysadmins de Linux, engenheiros DevOps, entusiastas de homelab, estudantes e pequenas equipas de TI.
Se precisas de paridade em RDP ou VNC para trabalho intensivo com desktops Windows, acompanha as releases. A distância está a diminuir, mas, por agora, mantém o mRemoteNG (em Windows) ou a tua ferramenta atual em paralelo.
Nada de marketing exaltado — é este o estado das coisas.
Migrar a partir do mRemoteNG
A migração é propositadamente rápida.
- 1Exporta ou localiza o teu
confCons.xmlatual (o ficheiro de ligações predefinido do mRemoteNG). - 2Instala o Remota na tua estação de trabalho Linux com um dos comandos abaixo.
- 3Importa o ficheiro. Pastas, hosts, protocolos, definições de jump host e credenciais guardadas passam de uma só vez.
- 4Define a tua palavra-passe mestra do Remota — passa a ser a chave que desbloqueia o cofre local a partir de agora.
Não estás a reconstruir o teu mundo. Estás a mudá-lo de sítio.
Como instalar
O Remota é distribuído como três artefactos para Linux x86_64. Descarrega a release mais recente do GitHub e instala-a com o teu gestor de pacotes, ou corre-a diretamente 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.rpmQualquer Linux x86_64 (portátil):
chmod +x Remota_*.AppImage
./Remota_*.AppImageDescarrega os ficheiros da release atual na página de releases do Remota no GitHub. Os nomes dos pacotes incluem a versão — troca 0.1.2 pela tag mais recente se entretanto tiver saído uma build mais nova.
Experimenta o Remota
Grátis. Open source sob AGPL-3.0-only. Sem conta. Sem cloud. Sem telemetria.
- Página do produto: Remota — Gestor de ligações remotas open source para Linux
- Código-fonte: github.com/privum-cloud/remota
- Agente autoalojado: github.com/privum-cloud/remota-client
Se o mRemoteNG tem sido a forma de "como quero gerir as minhas sessões remotas" e o Linux tem sido a plataforma que nunca o teve, o Remota é a versão que finalmente o tem.
Perguntas frequentes
O Remota é um fork do mRemoteNG? Não. O Remota é um projeto clean-room inspirado no fluxo de trabalho do mRemoteNG — a experiência multiprotocolo, em separadores e organizada por pastas com a qual milhares de administradores ganharam memória muscular. Não partilha código com o mRemoteNG e usa um stack completamente diferente (Rust e Tauri em vez de .NET e WinForms).
Posso importar as minhas ligações do mRemoteNG? Sim. O Remota lê diretamente o ficheiro confCons.xml do mRemoteNG. Pastas, hosts, protocolos, definições de jump host e credenciais guardadas passam de uma só vez.
O Remota exige uma conta na cloud? Não. Tudo é local. As tuas credenciais vivem num cofre em disco cifrado com AES-256-GCM, desbloqueado apenas pela tua palavra-passe mestra. O NAT traversal, quando precisas dele, usa um relay alojado por ti na tua própria infraestrutura — e não os servidores do fornecedor de que o AnyDesk e o RustDesk dependem por predefinição.