HN Debrief

RustDesk now supports true unattended remote access on Wayland

  • Open Source
  • Security
  • Infrastructure
  • Developer Tools
  • Linux

RustDesk’s post announces “true unattended remote access” for Wayland, which is the long-missing piece for Linux remote admin on modern desktops. In practice, this means access before a user logs in and control of the physical desktop session, something Wayland has made much harder than X11 and one reason Linux remote support has lagged behind Windows. People who had just hit this limitation were happy to see it fixed, and several said RustDesk has become their replacement for TeamViewer, AnyDesk, or VNC because it works through NAT without manual port forwarding and usually feels much faster than framebuffer-based tools.

If you are evaluating remote desktop for Linux fleets, RustDesk looks notably more usable than classic VNC on performance and NAT traversal, especially for Wayland. Do a security and licensing review before standardizing on it, particularly if you plan to self-host or rely on its built-in auth instead of wrapping it in WireGuard, Tailscale, or SSH.

Discussion mood

Positive on the Wayland milestone and on RustDesk’s day-to-day usability. Cautious to negative on security hygiene and increasingly skeptical about how open the project really is.

Key insights

  1. 01

    Why it feels faster than VNC

    RustDesk gets its speed advantage by behaving more like a video stream than a remote framebuffer. That breaks the old VNC tradeoff where every screen change turns into image updates, so over WAN links and busy desktops it can feel like a different class of tool rather than a nicer VNC wrapper.

    If your team still reaches for VNC by default, test a codec-based remote desktop product before spending more time tuning VNC. The gain is largest on high-latency links, multi-monitor setups, and anything with frequent screen motion.

      Attribution:
    • pizza234 #1
    • rcxdude #1
    • fsh #1
  2. 02

    The encryption complaint was overstated

    The big security warning making the rounds was too broad. The documented setup uses end-to-end encryption through RustDesk’s rendezvous or relay architecture, including when you self-host those servers. The unresolved problem is direct IP access on a local network, where transport encryption is missing and disabled by default for exactly that reason.

    Do not repeat “self-hosted RustDesk is unencrypted” as a blanket claim. Check which connection mode you plan to use, and avoid direct IP access unless you add your own transport security.

      Attribution:
    • wooben #1
    • innocent_name #1 #2
  3. 03

    Wayland unattended access likely needs privileged capture

    Getting the login screen and physical seat over Wayland usually means bypassing desktop APIs and talking closer to the graphics stack. The comment points to DRM and KMS capture plus uinput-style device emulation, which explains why unattended remote control is hard on Wayland and why these tools tend to need elevated privileges.

    Treat unattended Wayland remote access as a privileged system component, not just another desktop app. Review how it is installed, what device nodes it can access, and what “remote control of the physical seat” means for your threat model.

      Attribution:
    • jchw #1
  4. 04

    Open source status is no longer clean

    The reassuring line that RustDesk is fully open source no longer holds cleanly if key pieces depend on unlicensed submodules or proprietary blobs. That turns the product from straightforward AGPL software into something you need to inspect package by package, and it is why forks like BetterDesk came up immediately.

    If licensing clarity matters for procurement, redistribution, or security review, audit the exact components you will ship. Do not assume “source on GitHub” gives you the same rights or visibility across the whole stack.

      Attribution:
    • pyramidless_cle #1
    • 9cb14c1ec0 #1
  5. 05

    The custom auth design triggered real concern

    One code-reading comment was far more damning than the generic password-policy bikeshedding. It flagged SHA-256 based password handling, a custom protocol built around NaCl boxes, and fallback behavior that looked unsafe in a security-sensitive client. Even if some of those observations need deeper validation, they are enough to explain why experienced operators want an extra encrypted and authenticated layer in front of RustDesk.

    If you plan to deploy RustDesk in a business setting, have someone competent review the protocol and auth path or isolate it behind a VPN. Product polish and protocol trust are separate questions.

      Attribution:
    • minitech #1
    • strbean #1

Against the grain

  1. 01

    Performance is not universally better

    The broad claim that RustDesk simply outperforms VNC ran into direct reports of the opposite. One person saw extreme client CPU usage plus GPU decode load, and another said TightVNC was good enough to make them uninstall RustDesk. That does not erase the architectural advantage, but it does puncture the assumption that newer codec-based tooling always wins on real machines.

    Benchmark on your actual client hardware before rolling this out to support staff or thin devices. Decode cost, drivers, and bugs can erase the theoretical protocol advantage.

      Attribution:
    • shock #1
    • diego_moita #1
  2. 02

    Built-in encryption does not replace a VPN

    Some people pushed back on the idea that modern apps should make overlays like Tailscale obsolete. They want VPNs and mutual auth precisely so internal tools stay off the public internet, and they value device identity, hardware-backed auth, and broad network isolation beyond what a single app can provide.

    Even if RustDesk improves its native crypto, that does not remove the case for WireGuard or Tailscale in a company environment. Decide whether you need just an encrypted session or a private administrative network with stronger access control.

      Attribution:
    • mnahkies #1
    • elevation #1
    • marshray #1

In plain english

AGPL ↩
Affero General Public License, a copyleft software license that requires source code to be offered to users of modified software, including in some networked use cases.
DRM ↩
Digital Rights Management, technical controls used by media companies to restrict copying and playback of digital content.
KMS ↩
Kernel Mode Setting, the Linux kernel interface used to set display modes and manage screens.
LAN ↩
Local Area Network, a network covering a small area such as a home, office, or data center rack.
NaCl ↩
Networking and Cryptography library, a set of cryptographic primitives and APIs used to build encrypted communication.
NAT ↩
Network Address Translation, a common router behavior that lets many devices share one public internet address and often blocks direct inbound connections.
RDP ↩
Remote Desktop Protocol, a Microsoft protocol for remotely controlling another computer’s graphical desktop.
SHA-256 ↩
Secure Hash Algorithm 256-bit, a cryptographic hash function often used in security systems but not ideal by itself for password storage.
uinput ↩
A Linux kernel interface that lets software create virtual input devices such as keyboards and mice.
VNC ↩
Virtual Network Computing, a remote desktop system that lets one device view and control another's screen.
WAN ↩
Wide Area Network, a network connection that spans larger distances, such as internet paths between cities or countries.
Wayland ↩
A modern Linux display protocol that replaces parts of the older X11 graphics system and supports tighter security boundaries.
X11 ↩
The older Linux and Unix windowing system that predates Wayland.

Reference links

RustDesk security and protocol references

Alternatives and forks

  • BetterDesk
    Mentioned as a fork or alternative in response to licensing concerns around RustDesk.

Password security references

Background protocol reference

  • Remote Desktop Protocol
    Linked during the comparison between Wayland remote access and longstanding Windows remote desktop support.