RustDesk agora oferece acesso remoto verdadeiro e não supervisionado no Wayland

Artigo original ↗ Discussão no Hacker News ↗

A nova capacidade do RustDesk de oferecer acesso remoto não supervisionado em desktops Linux Wayland é bem recebida como uma alternativa rápida e de código aberto a ferramentas como TeamViewer, AnyDesk, VNC e RDP, especialmente para configurações auto-hospedadas e suporte técnico. Os comentaristas destacam bom desempenho e facilidade de uso, mas levantam preocupações sobre políticas de senha, design criptográfico, ausência de criptografia em conexões diretas na LAN e alguns componentes fechados ou sem licença no projeto. O recurso também evidencia a fricção contínua no ecossistema Wayland, onde capacidades básicas como controle remoto completo ainda exigem gambiarras de baixo nível com DRM/KMS e extensões específicas do compositor.

Sentimento geral

  • Muitos estão entusiasmados com o RustDesk como substituto de TeamViewer/AnyDesk que “simplesmente funciona”, pode ser auto-hospedado e evita contas/vínculo ao fornecedor.
  • Outros estão cautelosos ou negativos devido a dúvidas de segurança, alto uso de recursos em alguns sistemas e preocupações com Wayland/implementação.

Casos de uso e comparações

  • O principal atrativo: acesso remoto não supervisionado a desktops Linux (incluindo Wayland), suporte técnico e uso geral de GUI remota.
  • Vários observam que você já pode fazer coisas semelhantes com VNC, Xpra, RDP, Remmina via SSH ou apenas SSH; o RustDesk é visto como mais uma opção, não algo fundamentalmente novo.
  • Comparado com VNC:
    • Vantagens alegadas: melhor desempenho via codecs de vídeo, suporte a múltiplos monitores, traversal de NAT mais fácil (sem necessidade de encaminhamento de portas/VPN).
    • Contraexemplos: alguns relatam uso de CPU extremamente alto e, na prática, preferem TightVNC ou TigerVNC.
  • Comparado com Sunshine/Moonlight e Steam Link:
    • O RustDesk é visto como mais fácil e menos “janky” fora de redes locais, mas o Sunshine é citado como uma forte referência técnica para captura em Wayland/DRM.

Wayland e implementação técnica

  • Nova funcionalidade: acesso verdadeiro e não supervisionado no Wayland, resolvendo um ponto de dor de longa data também visto no OBS e em outros.
  • Provavelmente usa um daemon privilegiado com captura de framebuffer via DRM/KMS e injeção de entrada no estilo uinput, semelhante ao Sunshine.
  • Uma dependência (libdrmtap) fornece apenas captura de tela; a entrada ainda é específica do compositor, então o suporte Wayland completo e universal continua confuso.
  • Alguns criticam o design do Wayland por tornar casos básicos de desktop remoto muito mais difíceis do que no X11 ou no Windows histórico (RDP/Terminal Services).

Segurança, senhas e criptografia

  • Política de senhas:
    • Alguns querem senhas no estilo frase-senha (XKCD) e não gostam das regras de complexidade do RustDesk.
    • Outros argumentam que frases curtas baseadas em palavras são facilmente quebráveis com GPUs de consumo quando armazenadas com hashes rápidos (MD5/SHA-256).
    • Contra-argumentos enfatizam a matemática de entropia, tentativas online limitadas por taxa e os benefícios de frases-senha mais longas; a sugestão é que um KDF como Argon2 seria melhor que SHA-256.
  • Um comentarista examinou o código do RustDesk, alega um esquema de desafio customizado baseado em SHA-256 com documentação pouco clara e possível risco de MITM, e recomenda não usar o software.
  • Criptografia:
    • Sessões normais do RustDesk via servidor (inclusive auto-hospedado) são relatadas como criptografadas de ponta a ponta usando boxes baseados em NaCl.
    • Conexões diretas por IP em “rede local” não são criptografadas, vêm desativadas por padrão e são oficialmente consideradas um recurso de teste; os mantenedores sugerem usar uma VPN (WireGuard/Tailscale) em vez disso.
    • Alguns consideram a falta de criptografia embutida para link direto uma omissão séria; outros dizem que LAN+VPN é suficiente.

Status de código aberto e ecossistema

  • O RustDesk é divulgado como código aberto, incluindo o servidor.
  • Críticos apontam:
    • Um submódulo obrigatório sem licença, e DLLs de código fechado para alguns recursos, colocam o projeto numa zona cinzenta entre open source e source-available.
  • Uma implementação alternativa de servidor (BetterDesk) é mencionada:
    • Usa um único binário Go com uma interface web opcional em Node.js/Postgres (SQLite por padrão).
    • Alguns gostam da arquitetura; outros criticam o que percebem como excesso e a sensação de projeto gerado por IA.

Recursos ausentes e pontos menores

  • Recursos desejados:
    • Cliente web auto-hospedado.
    • Passagem de entrada de microfone (atualmente não funciona; um usuário depende de um dispositivo separado, tipo KVM de hardware, como solução alternativa).
    • Suporte claro para máquinas totalmente headless é solicitado, mas não respondido.
  • Alguns detalhes menores:
    • Problema de CSS no menu/notificações.
    • Confusão em torno de “criptografado quando auto-hospedado” versus modo de IP direto.
    • Sentimentos mistos sobre a postura dos mantenedores de “não planejamos implementar isso, mas PRs são bem-vindos” em relação à criptografia na LAN.

Rede e discussões sobre “zero trust”

  • Vários usuários combinam RustDesk com Tailscale ou WireGuard para criptografia, controle de acesso e para evitar expor serviços à internet pública.
  • Outros argumentam que ferramentas de desktop remoto deveriam oferecer nativamente transporte seguro (por exemplo, TLS/QUIC com autenticação adequada ou TOFU) sem depender de uma VPN.
  • Ideias mais amplas mencionadas: OIDC/WebAuthn, autenticação de cliente baseada em chave SSH, IPv6 + DNS dinâmico, descoberta de endereços baseada em DHT (iroh/pkarr) e frontends zero-trust (Envoy, Authelia) para serviços auto-hospedados.