RustDesk now supports true unattended remote access on Wayland
rustdesk.com
rustdesk.com
Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by default.
If your use case is focused on direct connections without a server, RustDesk is the wrong tool for the job. It's an open-source self-hostable analog to Teamviewer, the server is inherent to the design.
Client -- Relay Server -- Host
That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.
The use case where encryption is not supported is directly connecting by IP address, which is not the intended use for this software. It's an open source analog to TeamViewer, not a replacement for VNC or RDP. The direct connect functionality is there primarily for testing, which is why it's entirely disabled by default and the option to turn it on is buried at the bottom of a dialog that requires elevated privileges to access. If your use case is focused on those direct connections, RustDesk is not aimed at you.
VNC does not, for example, and you need to set up port forwarding through ssh. X2Go does....but I don't trust it terribly. So, RustDesk..what do you need to wrap it in? ssh?
I really want a better solution that VNC/X2Go..especially since I use hardware accelerated apps that need to use VGL to operate correctly (but underwhich operation is quite buggy).
Another valid alternative is Xpra, and it does support Wayland too - but doesn't reach feature parity with X11. Like RustDesk, Xpra is similarly feature-rich and mature, it too can take advantage of SSH tunnels, SOCKS or HTTPS proxies etc.
And then there's TeamViewer and AnyDesk - both of which are paid, with a free tier for evaluating or personal use - RustDesk is younger, but feature-wise they're quite similar.
Finally, you could set up wireguard that will happily encrypt your connection with very little overhead - regardless of your chosen remote desktop solution.
I think such setups are at least as secure as having tailscale in front of it and they are web standards conform. I dont need a client app like tailscale, I can just use my normal browser and internet conn.
I always make sure envoy/all other apps are on the latest security patcb anyways.
I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.
What all user-facing software should have is a minimal-overhead connection option to improve performance inside user's tunnel of choice.
Pure QUIC gets blocked easily, SSH requires wrapping, even Tailscale mimicry is basic and they still ignore simple protocol improvements available.
basically an embedded tailscale.
> The public relays we run have seen more than 200 million endpoints created, in the last 30 days alone
Please just make it work seamlessly with my existing SSH credentials. Like SFTP.
But yeah, you could also make use of your ed25519 ssh public key as client certificate and accept based on fingerprint like ssh
Nothing prevents RustDesk from implementing TLS TOFU (see e.g. Gemini Protocol), which offers the same security guarantees as SSH TOFU.
Factually incorrect. If you self host a relay/coordination server - encryption works as documented.
[1] https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
"We don’t plan to implement this directly, as it is designed for test initially, we do not recommend using RustDesk with a public IP alone, that's also why direct ip access is turned off by default.
For security and privacy, we strongly advise using it in combination with a VPN—the VPN tunnel already provides end-to-end encryption, so additional encryption within RustDesk is unnecessary in that setup.
That said, we welcome community contributions! Many users express interest or share feedback—but very few take the next step and submit a pull request. If you’re able to help, your PR would be greatly appreciated! "
hate this. "we don't want this on principle... but we would accept it if you did it yourself!" just say you don't feel like it! don't act like it's a bad thing except for when somebody else does it for you, that's just dishonest.
What is there to hate here, I don't understand?
They first provide a concise overview of the current situation. Then how they personally feel about it. Finally they leave it open and end it with "If you want it badly enough, we'll accept outside contributions for it".
They're not saying that they're against the feature in principle, they're saying that they themselves don't plan to spend time implementing it, but if users really want it and contribute the feature itself, they'll be happy to maintain it once merged.
This seems like the ideal solution? What would be better here?
I certainly interpreted the response as meaning that anyone actually trying to implement the feature would find the PR an exercise in frustration. It may be there were some cultural confusions about context and implication, but considering that they locked the issue, people weren't exactly encouraged to ask for clarification. And the developers have a sketchy enough reputation already from other incidents.
Yeaah, both these points kind of makes it clear that both you and the author might have previous history with the history that goes beyond the messages that were referenced, and I don't have that context at all. I have no idea what "previous incidents" you might be referring to, so with that said I'll say that everything I've previously stated only been based on the text of that particular issue, nothing else. Based on the text from the issue alone, seems they're open to have the feature proposed as a PR to them, then if they typically reject any PRs, I have no idea about.
Then they say you should contribute it. It's mixed messaging, it seems like they're trying to hide "won't implement this" behind "this is a bad idea in general". They should just say they won't implement it and that they're open to contributions, not that it's a bad idea and that they "strongly" recommend against it, but that maybe if someone opens a PR anyway they'll consider it.
Massive misunderstanding from your perspective if this is your take away. They're saying that based on the current state of the program, they don't recommend that particular approach. Nowhere in that quote of yours, does it give an indication that they don't want that feature. The only thing unambiguous from that quote, is that due to the current state of the program, they don't recommend that approach, and explains why one of the defaults is like it is.
If they didn't like the idea, or didn't want the feature, they'd say so, but they do not say that out loud, so why would you assume so?
but I think it's phrased pretty stupidly, especially by pointing out to the askers that "very few" submit a pull request. that's just, shaming? "stop asking, do it yourself" which I hate just as much as hiding your real response behind recommendations.
That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming.
Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
I understand a lot of projects take this attitude but that doesn't mean it's always deserved.
> Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for stuff, you don't want to spend the time implement it, so you tell them to implement it themselves, and you'd accept it if they wanted it upstream to make it available for all. Isn't this the ideal scenario?
I think it's upsetting here. Not "bad", not even necessarily inappropriate or disproportionate but upsetting. Not because I wanted them to do the work for me but because I would have wanted to feel actually welcome to do the work myself instead of made to feel like it would be a further annoyance.
This kind of attitude from the project genuinely makes it feel like if I opened a PR, it would sit and rot just like the many issues have. It does not make me feel like they are actually interested in the problem or empathize with their users whatsoever, so what motivation would they have to accept the work even if it was done for them?
> I still don't understand what you think would be better here? Saying "No, we don't want that" even if they're OK with the feature existing? Or saying "Yes, we don't need it, but we'll put aside our needs just for you" would have been better?
Did you not see the example I already posted elsewhere in the thread? Here it is again: I prefer when projects say "we don't have the resources for this but we agree it would be nice"
Here, they aren't agreeing with it whatsoever, they just say they don't have it and that they don't recommend using the related features and that they won't consider it without a pull request. That's basically "we don't have this, won't build this and won't consider user requests" and it has absolutely nothing positive for the people who would build such a PR.
As much as they technically don't need such things because they're perfectly clear and if you don't like it you can suck it up or fork or quit computing to go live on a farm, do you not see how their response could have been better? They could be encouraging people to submit PRs but instead they're shaming people for not doing it. That response would only be deserved towards people who genuinely have expressed that they want it for free, but nobody has expressed this and yet they are still taking this attitude. It's disappointing and does not foster a culture of genuine contribution, just a culture of "stop being entitled"
Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted.
It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
> They could be encouraging people to submit PRs
The text I read, gave me the impression they are encouraging people to submit PRs, but maybe there is something between the lines I'm missed when I read it.
> It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.
I was a member of a discussion I linked in another comment about password complexity requirements, but I do not have experience with raising other issues or trying to get features accepted, so none of this is a simple grudge, just a very pedantic reading of their response.
I do have experience with manipulators that use exactly this kind of language to make good implications that they don't actually intend to honor. (Including myself at points.) So maybe my reading is unnecessarily pessimistic, but it's not based on some prior experience with them, just the particular way they made their statement.
Again, to me it's 100% clear they would accept a PR, but I guess there is nuance in "we welcome community contributions" and "your PR would be greatly appreciated"...
Also again, obviously you've already made up your mind. But as the perspective of someone who never interacted with the project, the impression (based on their words) is that they'd like a PR for this feature.
Besides "they don't intend to honor it!1!" which is essentially a guess, do you have any previous cases where they actually explicitly said they'd accept a contribution and then they dragged their feet accepting it/rejected it?
1 - https://github.com/rustdesk/rustdesk/issues/3714#issuecommen...
>RustDesk is a single open-source application (AGPL) with its own architecture. Clients connect outward to an ID/rendezvous server, which brokers a peer-to-peer or relayed session. Per the RustDesk documentation, traffic is end-to-end encrypted (built on NaCl)
You either pick a middleman you want to trust or you run one of your own, if you don't want that or need the features if offers RustDesk is not for you.
I will note that the XKCD password scheme being proposed there is, in fact, completely insecure. A modern consumer GPU can crack "four random English words" in a day. You can argue that it's the user's choice to be allowed to use insecure passwords, but arguing that that scheme is actually secure is just wrong.
Let's run the math:
EFF's long wordlist[0] (the one used by Bitwarden's passphrase generator) has 7776 words, which is about 13 bits of entropy per word (log2(7776) = 12.92). A 4-word passphrase then has 51.7 bits of entropy, meaning there are 2^51.7 possible options for the passphrase, which is 3.66E15 possible options.
For reference, a password with all completely random characters and symbols, for each character you have 70 possibilities, or about 6 bits of entropy. An 8-character completely random password (no words or the usual patterns) then has about 49 bits of entropy, which is less than a 4 word passphrase.
About the time it takes to crack it, assuming you can test an average of 1 password per μs (you probably can't, as passwords are usually stored using key derivation functions[1][2] with work factors tweaked for current hardware) it would take ~116 years to crack it. I usually see 5-passphrase recommended nowadays, which would multiply the required effort by 7776.
Sure, a 16-character random password has a lot more entropy, but it's also a lot harder to interact with (reading, comparing, typing) if you end up needing to, and it's still easier to crack than an 8-word passphrase.
[0] https://www.eff.org/dice [1] https://en.wikipedia.org/wiki/Key_derivation_function [2] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
Let me do just that!
This is a networked service. You send your password (or a hashed form) to it, and it validates it. You don't have the local hash to bruteforce it offline.
Even if we only consider the top 10k english words, it's 10000^4. It's going to take years to bruteforce this over a network because you'll go through so many rate-limits, cooldown periods, and outright bans that it's questionable whether it's even possible.
Hopefully neither. But given everybody involved in VNC seems to be the same batch of clueless morons who built all those PHP web forums twenty years ago with MD5 as the password hash, who knows what they cobbled together. Maybe an expert can chime in about what actually happens here?
Yes, for a sensible scheme this can't work.
I would recommend never using this software.
[1]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [2]: https://github.com/rustdesk/rustdesk/discussions/8392 [3]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2... [4]: https://github.com/rustdesk/rustdesk/blob/7aa98d43cf1962a7a2...
This is just completely false.
I proposed replacing the ridiculous checklist with zxcvbn.
I agree xkcd's scheme is a bad example and distracts from the real point, which is that a checklist is fundamentally bad, not that some specific password format should be allowed.
Plenty of sentence passwords meet that but now the probability space has exploded.
Sure, if you can rely on users using a specific format. The joy of the xkcd technique is you don't need to tell other people what yours is.
But, people just aren't going to remember strings of gibberish. Expecting users to do this is just silly.
If you were willing to use a bespoke, more secure variation of it, you could include a capital letter and a number rather than filing an issue on a repo insisting that you be allowed to use exactly the insecure variation.
For instance, I have multiple separator characters, multiple beginning and end characters, and numbers places at specific places, and arbitrary casing. That may be overkill but it's still essentially the xkcd format.
XKCD's youtube videos get millions of views each. It is a very popular comic, and that particular password advice has spread beyond it.
> What you describe as "bespoke" is likely the normal way someone might use it.
And yet the issue in question is about someone who refuses to adapt it.
Tayloring your format to the requirements of each site is a step towards defeating the utility of the system; now the user needs to remember some arbitrary hard-to-remember details for each password.
Although having a standard format for your passphrases across sites removes some of the advantages over just using the exact xkdc format (when one of your passwords is compromised and attackers can guess your custom format elsewhere now)...
That phrase will pass almost every single password requirement, and no one is going to crack it by brute force dictionary attack.
Does this person exist?
Edit: i appreciate the explanations; thank you.
It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.
Going on what the poster above says about CPU and memory - if the network speed or bandwidth allocation is the bottleneck, then trading CPU and memory utilisation increases for lower bandwidth is likely acceptable. If, however, the device is low end and tying up memory and CPU with compression would lead to sluggish or impaired task performance but the network has adequate overhead for lower levels of compression or higher levels of data transfer then higher network utilisation would be preferable.
Different tools, different use case scenarios.
However, I would say that high CPU or GPU usage is not necessarily an indicator of bad performance, especially since higher utilization can mean better performance.
How dare they.
That's what made me uninstall RustDesk.
If you're experiencing a bug that pegs you're CPU, fair enough. But RustDesk is video-stream based (in many formats), while TightVNC is image(-region) based. This is actually similar to why you watch movies in, say, H.264 rather than Motion JPEG¹.
¹=similar, not same.
No, thanks.
As they say: "the proof of the pudding is in the eating". So I used both applications and TightVNC is just a lot better, particularly in constrained remote VMs.
Docs are cheap, performance is what matters.
How do you know if the performance you get is the expected, unless you read the docs or at least look at what others get on similar platforms/environments/specs?
> TigerVNC was originally based on the (never-released) VNC 4 branch of TightVNC.
It seems to be popular, that’s why I’m asking.
Funny thing is that the document where they'd explain their reasoning to fork TightVNC returns 404.
If you already use VNC this is not something for you
I just glanced over the repo, deployment and comments around it and it seems like unconstrained AI slop or at least the project seems to be led by a person which can't use AI effectively for the purpose of software engineering.
Not that RealVNC is VNC. However, enshittification has clearly taken another scalp.
And since the paid pro version does have authentication, I think it's unlikely to ever show up in the free version.
How does RustDesk compare with that?
GNOME Remote Login runs an RDP server, and RDP indeed isn’t fast enough, although is TLS-encrypted.
There's VNC and VNC-likes (rdp, steam link, rustdesk, etc) which all do similar: stream a screen, allow remote keyboard/mouse, maybe redirect sound, maybe use video encoders.
There's also things like deskflow, which allow you to use one keyboard/mouse and control with multiple machines.
Does it framebuffer grab the current session and inject input events?
It entirely sidesteps the problem of X vs Wayland, although this does mean the unattended physical seat can be physically taken over while you are remote.
The basic idea is to enumerate the CRTCs to get the relevant framebuffer plane resources and then use dma-buf exports to pass them to an encoder. Reality can be a bit more complex due to the existence of overlay planes but that's the idea.
https://github.com/LizardByte/Sunshine/blob/master/src/platf...
So far it's only feature I found missing compared to proprietary solutions.
Now, VNC might actually also work very well over WireGuard or SDN based on WireGuard. Since VNC was designed for LAN, in a time where LAN was the common use case.
For me, low latency is from the past. I always got either wired, Wi-Fi, LTE, or Starlink.
I have used RustDesk for years, also run my own lookup/relay server so I do not need to rely on the public lookup server
While everything else gets enshitified RustDesk just keeps getting better
And the fact it's self-hosted is priceless.