RD-API-Server v1.4.5

This server can no longer hand out a private key, however it is configured.

Why it could

The API server never signs anything. It holds the RustDesk server key for one purpose: giving it to clients and to the browser viewer, which use it to verify that the server signing a handshake is the one they were configured for. Verification needs the public half and nothing else — a search of the codebase finds no signing call at all, and the key is read in exactly two places, both of which hand it out.

It was nonetheless possible to configure the wrong half. An Ed25519 signing key is 64 bytes — a random seed followed by a copy of the 32-byte public key — and RustDesk writes the two side by side:

id_ed25519.pub	32 bytes. Belongs in RUSTDESK_PUBLIC_KEY; goes to clients
id_ed25519	64 bytes. Stays on the server; never distributed

Point the configuration at the second, and this server published — to every client that requested a configuration — the key whose entire purpose is to prove the server's identity. Anyone holding it can impersonate the ID server to every client on the deployment.

Found on a live deployment: hbbs refused a connection presenting it, which is the only reason it surfaced.

What changed

Both distribution paths now go through one service that yields only the public half, deriving it when a private key is supplied.

Deriving rather than refusing is deliberate: an operator who made this mistake gets a working deployment and a loud diagnostic instead of a broken one and a puzzle, and hbbs rejects a client presenting a private key regardless, so passing it through helped nobody. The diagnostics page still reports the misconfiguration in full, prints the correct public key, and says to rotate.

A value that is neither half is dropped rather than distributed — a malformed key breaks every client with an error none of them can diagnose, while no key merely leaves the deployment unauthenticated, which is also reported.

If your configuration holds the private key, rotate the pair. Correcting the setting does not un-distribute what has already been handed out.

RUSTDESK_PUBLIC_KEY

A clearer name for the same setting, since the two filenames are nearly identical:

RUSTDESK_PUBLIC_KEY=<contents of id_ed25519.pub>
RUSTDESK_PUBLIC_KEY_FILE=/path/to/id_ed25519.pub

RUSTDESK_KEY and RUSTDESK_KEY_FILE keep working indefinitely. They are the conventional spelling across the RustDesk ecosystem, and breaking them would fail silently — an unset key disables peer verification rather than raising anything, so an upgrade would quietly downgrade security. The explicit name wins when both are set.

Upgrading

docker compose pull && docker compose up -d

No migration, no configuration change. Renaming the variable is optional.

Image

ghcr.io/gigaionllc/rustdesk-api-server:1.4.5

Multi-architecture (AMD64/ARM64), digest sha256:ef622af00af85e3f976973d0bd7ffcb95b8cfd649b9c544948c9d1b08616b62c. The latest, 1 and 1.4 tags point at the same manifest.

Verification

668 PHP tests, 253 web-client unit tests, 15 browser tests, Pint and PHPStan. Six new tests cover the key service directly: that a private key never leaves as one however it is configured, that a key file pointed at id_ed25519 is handled the same way, that a malformed value is dropped rather than distributed, and that the conventional environment name still resolves.

---

Full notes: docs/releases/v1.4.5.md

RD-API-Server is an independent, third-party, open-source project. It is not affiliated with, endorsed by, or sponsored by RustDesk or Purslane Ltd.