Manually •
Docker •
Keypair •
Binaries •
Variables
[French] | [Deutsch] | [Nederlands] | [繁體中文] | [简体中文] | [Русский]
This is a modified version of RustDesk Server, which is free and open source.
The webconsole is accessible at the address http://<server-ip>:21114/
with login "admin" and password "Hello,world!" .
You can browse the API documentation in the builtins API server at the address http://<server-ip>:21114/api/doc/
.
A non interactive API documentation is available at sctgdesk-api-server repo.
If you appreciate my work, please consider giving it a star! 🤩 or a
You can use the following docker-compose.yml
file to start the server:
version: '3'
networks:
sctgdesk-net:
external: false
services:
hbbs:
container_name: hbbs
ports:
- 21114:21114
- 21115:21115
- 21116:21116
- 21116:21116/udp
- 21118:21118
image: sctg/sctgdesk-server:latest
command: hbbs -r sctgdesk.example.com:21117
volumes:
- ./data:/usr/local/share/sctgdesk
networks:
- sctgdesk-net
depends_on:
- hbbr
restart: unless-stopped
hbbr:
container_name: hbbr
ports:
- 21117:21117
- 21119:21119
image: sctg/sctgdesk-server:latest
command: hbbr
volumes:
- ./data:/usr/local/share/sctgdesk
networks:
- sctgdesk-net
restart: unless-stopped
and start the server with:
mkdir -p data
docker-compose up
Binaries are available for the following platforms:
The default admin user is created with the username admin
and the password Hello,world!
. You can change the password after the first login on the webconsole.
The api standalone version is a version of the server that includes the API server and the webconsole but not the rendez-vous server.
The standalone version is available in its own repository sctgdesk-api-server.
For all api or webconsole related issues, please refer to the sctgdesk-api-server repository.
We modified our client to retrieve the autoupdate links from the api server rather from Github releases.
For having the autoupdate links working, you need to modify your client to retrieve the autoupdate links from the api server. This how you can do it:
// src/common.rs
#[tokio::main(flavor = "current_thread")]
async fn check_software_update_() -> hbb_common::ResultType<()> {
let url=format!("{}/api/software/releases/latest",get_api_server("".to_owned(), "".to_owned())).to_owned();
log::info!("URL for checking software updates: {}", url);
//let url = "https://github.com/rustdesk/rustdesk/releases/latest";
let latest_release_response = create_http_client_async().get(url).send().await?;
let latest_release_version = latest_release_response
.url()
.path()
.rsplit('/')
.next()
.unwrap_or_default();
let response_url = latest_release_response.url().to_string();
if get_version_number(&latest_release_version) > get_version_number(crate::VERSION) {
*SOFTWARE_UPDATE_URL.lock().unwrap() = response_url;
}
Ok(())
}
The embedded API server is not secured nor protected agains DDOS attacks. A good practice is to use a reverse proxy in front of the API server. NGINX is a good choice for this purpose. HAProxy is also a good choice.
We use HAProxy in front of the API server in our production environment.
This is our configuration file for HAProxy it is provided as an example only. You should adapt it to your own needs.:
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
defaults
log global
retries 2
timeout connect 3000ms
timeout server 5000ms
timeout client 5000ms
frontend hbbs_wss
bind 0.0.0.0:21120 ssl crt /etc/haproxy/hbb.pem
default_backend hbbs_wss_backend
frontend hbbs_api
mode http
option forwardfor
bind 0.0.0.0:21114 ssl crt /etc/haproxy/api.pem
http-request set-header X-Forwarded-Proto https
default_backend hbbs_api_backend
frontend hbbs_api_443
mode http
option forwardfor
bind 0.0.0.0:443 ssl crt /etc/haproxy/api.pem
http-request set-header X-Forwarded-Proto https
filter compression
compression algo gzip
compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json
compression offload
default_backend hbbs_api_backend
frontend hbbr_wss
bind 0.0.0.0:21121 ssl crt /etc/haproxy/hbb.pem
default_backend hbbr_wss_backend
backend hbbs_api_backend
mode http
server srv_main 127.0.0.1:21113
backend hbbs_wss_backend
server srv_main 127.0.0.1:21118
backend hbbr_wss_backend
server srv_main 127.0.0.1:21119
The hbbs server is launched with
[Unit]
Description=Rustdesk Signal Server
[Service]
Type=simple
LimitNOFILE=1000000
ExecStart=/usr/bin/hbbs --api-port=21113 -k AucFCOYVWNHRkJnx13FFh7C0tmUZ3nei5wXKmlfK6WPYthz65fRavaA5HO/OIz2kq+bCSlAqBkZgvikwVGqw/Q== --mask=10.10.0.235/24 -r rendez-vous.example.org -R rendez-vous.example.org
#Environment="RUST_LOG=debug"
Environment="ALWAYS_USE_RELAY=Y"
Environment="OAUTH2_CREATE_USER=1"
Environment="S3CONFIG_FILE=s3config.toml"
Environment="OAUTH2_CONFIG_FILE=oauth2.toml"
WorkingDirectory=/var/lib/rustdesk-server/
User=
Group=
Restart=always
StandardOutput=append:/var/log/rustdesk-server/hbbs.log
StandardError=append:/var/log/rustdesk-server/hbbs.error
# Restart service after 10 seconds if node service crashes
RestartSec=10
[Install]
WantedBy=multi-user.target
To restrict access to your server, you can use the --logged-in-only
option or set the LOGGED_IN_ONLY=Y
environment variable for the hbbs
server. This will limit control to logged-in users only.
Even with this option enabled, users can still register on the Rendez-vous server, but they won't be able to control another user's peer. If someone tries to control a peer without being logged in, they'll receive an error message:
By enabling this feature, you can add an extra layer of security to your server and prevent unauthorized access.
Configuring LOGGED_IN_ONLY
To enable this feature:
LOGGED_IN_ONLY=Y
environment variable for the hbbs
server.--logged-in-only
option when running the hbbs
server.Example
To set the LOGGED_IN_ONLY
environment variable, you can add the following line to your ~/.bashrc
file or equivalent:
export LOGGED_IN_ONLY=Y
Self-host your own RustDesk server, it is free and open source.
First you need to have a working Rust development toolchain and a Node ≥ 20 working installation.
DATABASE_URL=sqlite://$(pwd)/db_v2.sqlite3 cargo build --release
set "DATABASE_URL=sqlite://%CD%/db_v2.sqlite3" && cargo build --release
Three executables will be generated in target/release.
You can find updated binaries on the releases page.
All released binaries after release v1.1.99-40 are attestated with Github Actions. You can check the attestation by checking the sha256sum of the binary with https://search.sigstore.dev/?hash=<sha256>
for example.
If you want extra features RustDesk Server Pro might suit you better.
If you want to develop your own server, rustdesk-server-demo might be a better and simpler start for you than this repo.
Docker images are automatically generated and published on every github release.
These images are build against ubuntu-22.04
with the only addition of the main binaries (hbbr
and hbbs
). They're available on Docker hub with these tags:
architecture | image:tag |
---|---|
amd64 | sctg/sctgdesk-server:latest |
arm64v8 | sctg/sctgdesk-server:latest |
arm32v7 | sctg/sctgdesk-server:latest |
You can start these images directly with docker run
with these commands:
docker run --name hbbs --net=host -v "$PWD/data:/usr/local/share/sctgdesk" -d sctg/sctgdesk-server:latest hbbs -r <relay-server-ip[:port]>
docker run --name hbbr --net=host -v "$PWD/data:/usr/local/share/sctgdesk" -d sctg/sctgdesk-server:latest hbbr
or without --net=host
, but P2P direct connection can not work.
For systems using SELinux, replacing /root
by /root:z
is required for the containers to run correctly. Alternatively, SELinux container separation can be disabled completely adding the option --security-opt label=disable
.
docker run --name hbbs -p 21114:21114 -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v "$PWD/data:/usr/local/share/sctgdesk" -d sctg/sctgdesk-server:latest hbbs -r <relay-server-ip[:port]>
docker run --name hbbr -p 21117:21117 -p 21119:21119 -v "$PWD/data:/usr/local/share/sctgdesk" -d sctg/sctgdesk-serverlatest hbbr
The relay-server-ip
parameter is the IP address (or dns name) of the server running these containers. The optional port
parameter has to be used if you use a port different than 21117 for hbbr
.
You can also use docker-compose, using this configuration as a template:
version: '3'
networks:
sctgdesk-net:
external: false
services:
hbbs:
container_name: hbbs
ports:
- 21114:21114
- 21115:21115
- 21115:21115
- 21116:21116
- 21116:21116/udp
- 21118:21118
image: sctg/sctgdesk-server:latest
command: hbbs -r sctgdesk.example.com:21117
volumes:
- ./data:/usr/local/share/sctgdesk
networks:
- sctgdesk-net
depends_on:
- hbbr
restart: unless-stopped
hbbr:
container_name: hbbr
ports:
- 21117:21117
- 21119:21119
image: sctg/sctgdesk-server-server:latest
command: hbbr
volumes:
- ./data:/usr/local/share/sctgdesk
networks:
- sctgdesk-net
restart: unless-stopped
Edit line 16 to point to your relay server (the one listening on port 21117). You can also edit the volume lines (line 18 and line 33) if you need.
(docker-compose credit goes to @lukebarone and @QuiGonLeong)
Note that here, the sctg/sctgdesk-server-server:latest in China may be replaced with the latest version number on dockerhub, such as sctg/sctgdesk-server-server:1.1.99-37. Otherwise, the old version may be pulled due to image acceleration.
A keypair is needed for encryption; you can provide it, as explained before, but you need a way to create one.
You can use this command to generate a keypair:
/usr/bin/rustdesk-utils genkeypair
If you don't have (or don't want) the rustdesk-utils
package installed on your system, you can invoke the same command with docker:
docker run --rm --entrypoint /usr/bin/rustdesk-utils sctg/sctgdesk-server-server:latest genkeypair
The output will be something like this:
Public Key: 8BLLhtzUBU/XKAH4mep3p+IX4DSApe7qbAwNH9nv4yA=
Secret Key: egAVd44u33ZEUIDTtksGcHeVeAwywarEdHmf99KM5ajwEsuG3NQFT9coAfiZ6nen4hfgNICl7upsDA0f2e/jIA==
Separate .deb packages are available for each binary, you can find them in the releases. These packages are meant for the following distributions:
hbbs and hbbr can be configured using these ENV variables.
You can specify the variables as usual or use an .env
file.
variable | binary | description |
---|---|---|
ALWAYS_USE_RELAY | hbbs | if set to "Y" disallows direct peer connection |
DOWNGRADE_START_CHECK | hbbr | delay (in seconds) before downgrade check |
DOWNGRADE_THRESHOLD | hbbr | threshold of downgrade check (bit/ms) |
KEY | hbbs/hbbr | if set force the use of a specific key, if set to "_" force the use of any key |
LIMIT_SPEED | hbbr | speed limit (in Mb/s) |
OAUTH2_CONFIG_FILE | hbbs | path for oauth2 config file |
OAUTH2_CREATE_USER | hbbs | if set to "1" create a user if it doesn't exist |
PORT | hbbs/hbbr | listening port (21116 for hbbs - 21117 for hbbr) |
RELAY | hbbs | IP address/DNS name of the machines running hbbr (separated by comma) |
RUST_LOG | all | set debug level (error|warn|info|debug|trace) |
S3CONFIG_FILE | hbbs | path for s3 config file |
SINGLE_BANDWIDTH | hbbr | max bandwidth for a single connection (in Mb/s) |
TOTAL_BANDWIDTH | hbbr | max total bandwidth (in Mb/s) |