RustDesk - TeamViewer/AnyDesk alternative

[fbartels]

I looked into this a few weeks ago and since Rustdesk does not bring a web ui of its own I switched my investigation to https://github.com/UNITRONIX/BetterDesk instead. That project had its quirks as well (for example it never generated the custom install clients but also did not give me logging to investigate this), so I did not pursue this any further.

But the code and a CloudronVersions.json can be found at https://git.9wd.eu/apps/cloudron-betterdesk for those that want to try it out and possibly continue with it.

[MiroTalk]

Yeah, having RustDesk available on Cloudron would be great! Since MiroTalk SFU is already packaged for Cloudron and supports RustDesk remote control, it would be a nice addition to the ecosystem.

MiroTalk SFU can enable this feature with the following env configuration:

REMOTE_CONTROL_ENABLED=true
REMOTE_CONTROL_DOWNLOAD_URL=https://rustdesk.com/

Users can use the official RustDesk infrastructure or their own self-hosted RustDesk server (hbbs/hbbr) for remote sessions. This would be a great addition for anyone looking to combine self-hosted video conferencing with remote desktop support.

Thank you!

[andreasdueren]

@MiroTalk would you like to test this package to see if this works as intended with MiroTalk? https://git.due.ren/andreas/rustdesk-server-cloudron/-/raw/main/CloudronVersions.json

[jdaviescoates]

@andreasdueren said:

@MiroTalk would you like to test this package to see if this works as intended with MiroTalk? https://git.due.ren/andreas/rustdesk-server-cloudron/-/raw/main/CloudronVersions.json

Is that new? I had a quick look at https://ca.cloudron.io/ and didn't see it there.

[MiroTalk]

@andreasdueren said:

@MiroTalk would you like to test this package to see if this works as intended with MiroTalk? https://git.due.ren/andreas/rustdesk-server-cloudron/-/raw/main/CloudronVersions.json

Yeah, I’ve just tested it, and it seems to work well with MiroTalk!

[andreasdueren]

@jdaviescoates I didn't publish this yet

[MiroTalk]

One small concern: the /setup page is publicly accessible, so anyone can view the server address and public key and potentially use the server as their own RustDesk relay. It might be worth considering the best approach for sharing these connection details securely, while still allowing legitimate participants to connect easily.

Overall, the package looks great. Thanks again for your work on it!

[andreasdueren]

@MiroTalk Yes it's public, assuming the other person on the mirotalk call is a stranger. We could put that behind OIDC?

[MiroTalk]

@andreasdueren said:

We could put that behind OIDC?

Maybe I'd keep it as it is for now to ensure zero friction for end users. We can always consider additional access controls later if needed. Let me thinking about... Thanks!

[timconsidine]

As there are so many bots, crawlers, spiders etc out there these days, I'd consider some level of protection, even if it is just conscious strong anti-bot. Not yet experimented with HeCAPTe (community app) but maybe that's something to consider for low user friction with a level of "go away" for bots & crawlers.

[robi]

It would be useful if the Cloudron nginx could proxy auth protected paths/routes defined in App packages and inject an allow list for logged in admins who installed it.

[MiroTalk]

Self-Hosted RustDesk Configuration for MiroTalk SFU (Cloudron)

Docker image build in progress...
MiroTalk SFU v.2.6.14

Configure the following environment variables in your MiroTalk SFU env file to use your own RustDesk server hosted on Cloudron:

# Enable presenter remote control requests (true|false)
REMOTE_CONTROL_ENABLED=true                      

# Allow public access to the setup page.
# true = anyone with the URL can access it
# false = access requires a valid token from a MiroTalk room request
REMOTE_CONTROL_DOWNLOAD_URL_PUBLIC=false

# Leave it empty here
REMOTE_CONTROL_DOWNLOAD_URL=

# RustDesk ID server hostname (e.g. rustdesk.example.com)
REMOTE_CONTROL_SERVER_HOST=

# RustDesk server PUBLIC key (contents of id_ed25519.pub)
# Never use or expose the private key (id_ed25519).
REMOTE_CONTROL_SERVER_KEY=

How It Works

By default, REMOTE_CONTROL_SETUP_PUBLIC=false, so access to the setup page requires a valid, room-bound token.

1. The presenter sends a remote-control request to a participant.
2. When the request is created, the server generates a signed token bound to the room, valid for 15 minutes.
3. The participant receives a Get RustDesk link pointing to /remote-control/setup?t=<token>.
4. The setup page validates the token. Requests with missing, invalid, forged, or expired tokens return 404 Not Found.

Optional: Public Setup Page

Set REMOTE_CONTROL_SETUP_PUBLIC=true to make the setup page publicly accessible without a token. Anyone with the URL can open it.

Security recommendation: Keep REMOTE_CONTROL_SETUP_PUBLIC=false to ensure setup links are time-limited and tied to the relevant room. This protects access to the setup page, while RustDesk relay security must still be configured separately.