RustDesk ahora admite acceso remoto desatendido real en Wayland

Artículo original ↗ Discusión en Hacker News ↗

La nueva capacidad de RustDesk para ofrecer acceso remoto desatendido en escritorios Linux con Wayland es bien recibida como una alternativa rápida y de código abierto a herramientas como TeamViewer, AnyDesk, VNC y RDP, especialmente para instalaciones autoalojadas y soporte técnico. Los comentaristas destacan su buen rendimiento y facilidad de uso, pero plantean preocupaciones sobre las políticas de contraseñas, el diseño criptográfico, la falta de cifrado para conexiones directas en LAN y algunos componentes cerrados o sin licencia del proyecto. La función también subraya la fricción continua en el ecosistema Wayland, donde capacidades básicas como el control remoto completo todavía requieren soluciones de bajo nivel con DRM/KMS y extensiones específicas del compositor.

Sentimiento general

  • Muchos están entusiasmados con RustDesk como sustituto de TeamViewer/AnyDesk que “simplemente funciona”, puede autoalojarse y evita cuentas o dependencia del proveedor.
  • Otros son cautelosos o negativos por dudas de seguridad, alto uso de recursos en algunos sistemas y preocupaciones sobre Wayland y la implementación.

Casos de uso y comparaciones

  • El atractivo principal: acceso remoto desatendido a escritorios Linux (incluido Wayland), soporte técnico y uso general de GUI remota.
  • Varios señalan que ya se pueden hacer cosas parecidas con VNC, Xpra, RDP, Remmina sobre SSH o solo SSH; RustDesk se ve como otra opción, no como algo fundamentalmente nuevo.
  • En comparación con VNC:
    • Ventajas alegadas: mejor rendimiento gracias a códecs de vídeo, soporte para varios monitores, y un mejor manejo del NAT (sin necesidad de reenvío de puertos ni VPN).
    • Contraejemplos: algunos informan un uso de CPU extremadamente alto y, en la práctica, prefieren TightVNC o TigerVNC.
  • En comparación con Sunshine/Moonlight y Steam Link:
    • RustDesk se percibe como más fácil y menos “torpe” fuera de las redes locales, pero Sunshine se menciona como una referencia técnica sólida para captura en Wayland/DRM.

Wayland e implementación técnica

  • Nueva función: acceso desatendido real en Wayland, resolviendo un punto de dolor de larga data que también se observa en OBS y otros.
  • Probablemente usa un daemon con privilegios, captura de framebuffer DRM/KMS e inyección de entrada estilo uinput, similar a Sunshine.
  • Una dependencia (libdrmtap) solo proporciona captura de pantalla; la entrada sigue siendo específica del compositor, así que el soporte completo y universal para Wayland sigue siendo complicado.
  • Algunos critican el diseño de Wayland porque hace que casos de uso básicos de escritorio remoto sean mucho más difíciles que en X11 o en Windows histórico (RDP/Terminal Services).

Seguridad, contraseñas y cifrado

  • Política de contraseñas:
    • Algunos quieren contraseñas tipo frase de paso (XKCD) y no les gustan las reglas de complejidad de RustDesk.
    • Otros argumentan que las frases de paso cortas compuestas por palabras se crackean fácilmente con GPUs de consumo cuando se almacenan con hashes rápidos (MD5/SHA-256).
    • Los contraargumentos subrayan la entropía, el rate limiting en intentos en línea y los beneficios de frases de paso más largas; se sugiere que un KDF como Argon2 sería mejor que SHA-256.
  • Un comentarista examinó el código de RustDesk, afirma que usa un esquema de desafío personalizado basado en SHA-256 con documentación poco clara y posible riesgo de MITM, y recomienda no usar el software.
  • Cifrado:
    • Las sesiones normales de RustDesk a través de un servidor (incluido uno autoalojado) se reportan como cifradas de extremo a extremo mediante cajas basadas en NaCl.
    • Las conexiones directas por IP en la “red local” no están cifradas, vienen desactivadas por defecto y oficialmente se consideran una función de prueba; los mantenedores sugieren usar una VPN (WireGuard/Tailscale) en su lugar.
    • Algunos consideran la falta de cifrado integrado para enlaces directos una omisión seria; otros dicen que LAN+VPN es suficiente.

Estado de código abierto y ecosistema

  • RustDesk se comercializa como código abierto, incluido el servidor.
  • Los críticos señalan:
    • Un submódulo requerido sin licencia, y DLL cerradas para algunas funciones, lo colocan en una zona gris entre open source y source-available.
  • Se menciona una implementación alternativa de servidor (BetterDesk):
    • Usa un único binario en Go con una interfaz web opcional en Node.js/Postgres (SQLite por defecto).
    • A algunos les gusta la arquitectura; otros critican un supuesto exceso y el aire generado por IA del proyecto.

Funciones faltantes y puntos menores

  • Funciones deseadas:
    • Cliente web autoalojado.
    • Paso de entrada del micrófono (actualmente no funciona; un usuario depende de un dispositivo hardware aparte tipo KVM como solución alternativa).
    • Se pregunta por compatibilidad clara con máquinas completamente sin monitor, pero no se responde.
  • Algunas observaciones menores:
    • Problema de CSS en el menú/notificaciones.
    • Confusión sobre “cifrado cuando está autoalojado” frente al modo IP directa.
    • Opiniones mixtas sobre la postura de los mantenedores de “no planeamos implementar esto, pero se aceptan PRs” respecto al cifrado LAN.

Redes y discusiones de “zero trust”

  • Varios usuarios combinan RustDesk con Tailscale o WireGuard para cifrado, control de acceso y para evitar exponer servicios a la Internet pública.
  • Otros argumentan que las herramientas de escritorio remoto deberían soportar de forma nativa transporte seguro (por ejemplo, TLS/QUIC con autenticación adecuada o TOFU) sin depender de una VPN.
  • Se mencionan ideas más amplias: OIDC/WebAuthn, autenticación de cliente basada en claves SSH, IPv6 + DNS dinámico, descubrimiento de direcciones basado en DHT (iroh/pkarr) y frontends de zero trust (Envoy, Authelia) para servicios autoalojados.