In terms of remote desktop, the blogger used to use TeamViewer. After various checks for commercial use and restrictions, they switched to the domestic ToDesk. However, recently ToDesk has also started imposing forced logins and various restrictions. Recently, I happened to see that Rustdesk has switched to an open-source model, so I explored and tried its usage, and the experience is really great~
1. Software Introduction#
RustDesk, as the name suggests, is an open-source remote desktop tool built on the efficient Rust language. I first saw this tool on V2EX, but at that time, self-hosting the server required a payment of 100 USD for a license, and the demo available for display could only achieve the simplest demonstration functions. The built-in server seemed to be located overseas, making it unsuitable for productivity software.
Recently, I saw group friends mention it again and found that RustDesk has open-sourced the server and allows users to set up their own relay servers. Since the start of the school year, I have frequently used remote desktop software because even when not in the office, I often need to record meetings, receive files, and attend online classes on the office computer. Since last year, I have been using ToDesk, but several recent versions of the main control have not only enforced logins but also added restrictions for Android-controlled devices. The free version only supports one device and can only be changed once a month. The software itself also has some small bugs; when the phone is used as the main control and disconnects, if the app is left in the background for a while and then reopened, it will prompt "Account not logged in," and only restarting the software will allow normal control of the computers in the account.
To summarize the advantages of using RustDesk in the past few days:
(1) Lightweight: Whether server or client, regardless of the platform, the software is compact and fully functional.
(2) Full platform support: Supports bidirectional control on Android, Linux, and Windows.
(3) Secure and controllable: The software is open-source, self-hosted server, and communication is encrypted.
(4) Efficient bandwidth: Only 2-3M is needed for smooth 1080P, supporting TCP hole punching for end-to-end P2P connections.
2. Preparation Work#
In addition to the main control and controlled mobile phones and computers used daily, all that needs to be prepared is a server.
3. Building the Server#
Rustdesk officially provides a docker deployment method, which makes it easy to set up the server. However, this article focuses on recording the manual configuration method, as Rustdesk itself has very low hardware requirements, and we want to maximize its advantages.
Official Documentation: Click here
The Rustdesk server (i.e., relay server) requires at least 3 ports, and the program occupies two others for implementing the web-based remote desktop (reference: Click here). The official documentation provides a brief explanation of the purpose of each port, and the table below gives a brief overview. I introduced a concept of "anchor points" because the custom port settings for the Rustdesk server are generated by specifying anchor points and then using -1, +2, rather than allowing you to arbitrarily specify five ports.
Port Number | Protocol | Program | Purpose | Anchor Point |
---|---|---|---|---|
21115 | tcp | HBBS | NAT type testing | |
21116 | tcp/udp | HBBS | TCP hole punching and connection service / UDP ID registration and heartbeat service | HBBS anchor point |
21117 | tcp | HBBR | Relay service | HBBR anchor point |
21118 | tcp | HBBS | WebSocket service | |
21119 | tcp | HBBR | WebSocket forwarding |
The precompiled packages for the 64-bit Windows/Linux HBBR and HBBS servers can be obtained from GitHub Release, while other architectures need to clone the source code and compile it using cargo (official documentation). If you encounter problems during the build, you can leave a message in the comments, and I can assist or improve this article.
GitHub Precompiled Package: Click here
The official documentation recommends using PM2 to manage the process (Click here), but I feel that installing a set of Node.js tools for a lightweight remote desktop tool is somewhat inappropriate. I still recommend using systemd for process management and enabling startup on boot.
HBBS#
First, give executable permissions to the extracted hbbs file using chmod +x hbbs
, then run ./hbbs
once to generate the public key id_ed25519.pub
for client authentication. Next, use the cat id_ed25519.pub
command to view the public key and note it down. Then, edit /etc/systemd/system/hbbs.service
with your preferred editor, modifying the following reference configuration as needed and saving it. At this point, you should also write the forced key verification with the -k _
parameter in the startup command.
⚠ Warning: I strongly recommend adding the
-k
parameter; otherwise, hbbs will not enforce verification of the client's key, which may lead to the relay server being used anonymously!
1234567891011121314151617181920 | # systemd configuration path# /etc/systemd/system/hbbs.service [Unit]Description=RustDeskServiceAfter=network.target [Service]Type=simpleUser=rootRestart=on-failureRestartSec=5s# Set the running pathWorkingDirectory=/program path/rustdesk# You can modify the anchor point ports, currently 21116 (anchor point) and 21115 (anchor point -1) and 21118 (anchor point +2)# -r is used to specify the network card IP (suitable for multiple network cards), -k parameter is used to enforce verification of the client's public key to avoid unauthorized useExecStart=**/program path/**rustdesk/hbbs-r0.0.0.0-p21116-k_ **[Install]**WantedBy=multi-user.target |
---|
HBBR#
First, give executable permissions to the extracted hbbr file using chmod +x hbbr
, then edit /etc/systemd/system/hbbr.service
with your preferred editor, modifying the following reference configuration as needed and saving it. Similarly, include the key verification with the -k _
parameter in the startup command.
hbbr.service
1234567891011121314151617181920 | # systemd configuration path# /etc/systemd/system/hbbr.service [Unit]Description=RustDeskServiceAfter=network.target [Service]Type=simpleUser=rootRestart=on-failureRestartSec=5s# Set the running pathWorkingDirectory=/program path/rustdesk# You can modify the anchor point ports, currently 21117 (anchor point) and 21119 (anchor point +2)# -k parameter is used to enforce verification of the client's public key to avoid unauthorized useExecStart=**/program path/**rustdesk/hbbr-p21117-k_ **[Install]**WantedBy=multi-user.target |
---|
To simplify this process, you can place the extracted precompiled hbbr
and hbbs
in the /home/rustdesk
folder and directly execute the contents of the two txt files (Click here) to create the service. Once the .service
is set up, you can start these two services using service hbbs start
and service hbbr start
. After starting, you can check the running status of the processes using service hbbs status
and service hbbr status
, and a green "Active" indicates everything is correct.
Once everything is ready, you can enable them to start on boot using systemctl enable hbbs
and systemctl enable hbbr
. Finally, for port release, the commands for iptables
, firewalld
, and ufw
are as follows, where the ports should be released according to your settings (default 21115-21117). Note that the hbbs anchor point port must be released for both tcp and udp. The web side is currently being tested, and since I do not have this requirement for now, I have not tried it. If you have good practices, feel free to share your experience in the comments!
Port Release
Shell
123456789101112131415161718 | #CentOS firewalldfirewall-cmd--zone=public--add-port=21115/tcp--permanentfirewall-cmd--zone=public--add-port=21116/tcp--permanentfirewall-cmd--zone=public--add-port=21116/udp--permanentfirewall-cmd--zone=public--add-port=21117/tcp--permanent #Debian/Ubuntu ufwufwallow21115/tcpufwallow21116/tcpufwallow21116/udpufwallow21117/tcp #iptablesiptables-IINPUT1-ptcp--dport21115-jACCEPTiptables-IINPUT1-ptcp--dport21116-jACCEPTiptables-IINPUT1-pudp--dport21116-jACCEPTiptables-IINPUT1-ptcp--dport21117-jACCEPTiptables-save//save (to solve the issue of failure after reboot) |
---|
4. Configuring the Client#
In the new version of the service, executing cat id_ed25519.pub
in the hbbs/hbbr running directory can obtain the public key used for client-server authentication (the operation in the picture is incorrect; thanks to the author for the correction).
In the Rustdesk client, find the [ID/Relay Server] option and set it to the server we set up with hbbs/hbbr (official documentation).
In the first item, fill in the server Server IP
and hbbs anchor point port
in the format of [IP], and in the second item, fill in the Server IP
and hbbr anchor point port
in the same format. In the fourth item, input the id_ed25519.pub
obtained earlier, and after saving, you can control other clients in the same way as ToDesk and TeamViewer using ID + key.
It is important to note that both the main control and the controlled must be set to the same ID/Relay Server
to connect and use normally. In addition, direct LAN IP connection can be enabled in the settings menu of the controlled device by allowing direct IP access, and then the main control can connect by directly entering [Controlled IP:21116]. For more detailed usage on other platforms, you can refer to the official documentation (Click here) for learning.
5. Conclusion#
RustDesk is undoubtedly an excellent open-source remote desktop tool. In the context of remote desktop tools repeatedly being exploited by commercial companies, it is a refreshing change that breaks this situation and brings us more choices.
Of course, RustDesk itself still has much room for improvement, such as making the screen fit the display better after connecting to the app, smoother startup of the QR code scanning function, and a more user-friendly interactive UI, etc. Based on similar software, it is speculated that RustDesk may have more efficient components like NVENC and a more complete account and control system in the future. I also hope RustDesk can maintain its open-source spirit and find a suitable way to profit, as it is impossible to rely solely on goodwill. Here is a link for the author to accept donations (Click here); if you have the means, consider supporting the author.
Finally, let's thank the author again for bringing such a useful software!
Reprinted from: Luminous' Home » 【RustDesk】Self-built Remote Desktop Service to Replace TeamViewer/ToDesk