Adam Moussa
9f18ecab50
Scaffold the CDK stack for a self-hosted RustDesk Server Pro relay so remote support no longer depends on the public RustDesk rendezvous/relay infrastructure. Single ARM64 EC2 (SSM-managed, no SSH) runs hbbs+hbbr in Docker. The server key pair and DB live on a standalone RETAINed EBS volume so they survive instance replacement (clients keep trusting the same key). Relay ports are public; the Pro admin console (21114) is restricted to the office VPN + VPC. IMDSv2 is enforced and the data dir is locked to root. EIP + rustdesk.seahaven.com give clients a stable address.
67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
# RustDesk Server — Runbook
|
|
|
|
Operational procedures for the `rustdesk-server` stack. Account 328440206208, us-east-1.
|
|
|
|
## Access
|
|
|
|
The instance is SSM-managed (no inbound SSH):
|
|
|
|
```bash
|
|
aws ssm start-session --target <instance-id> --region us-east-1
|
|
```
|
|
|
|
Find the instance: `aws ec2 describe-instances --filters Name=tag:Name,Values=rustdesk-server`.
|
|
|
|
## The data volume (read this before any redeploy)
|
|
|
|
All durable state — the `id_ed25519` server key pair and the sled database — lives on the standalone EBS volume `rustdesk-data`, mounted at `/var/lib/rustdesk`, attached at `/dev/xvdf`.
|
|
|
|
- It is declared as a separate `ec2.Volume` with `RemovalPolicy.RETAIN`, **not** an inline `blockDevice`. This is deliberate: an inline data volume gets replaced whenever CloudFormation replaces the instance, which would destroy the server key and force **every** client to re-trust the host.
|
|
- `userdata/bootstrap.sh` mounts the existing filesystem and only runs `mkfs` when `blkid` reports the device is blank, so reattaching to a fresh instance preserves data.
|
|
- Before any change that may replace the instance (AMI bump, instance-type change), confirm a recent EBS snapshot exists and that the key pair is mirrored to `rustdesk/server-key-pair`.
|
|
|
|
## Instance replacement
|
|
|
|
A replaced instance reattaches the same RETAINed volume and remounts it without reformatting, so the server key and DB are preserved. After replacement:
|
|
|
|
1. Confirm `docker compose ps` shows `hbbs` and `hbbr` healthy (`cd /opt/rustdesk`).
|
|
2. Confirm clients still connect without re-accepting a new key.
|
|
|
|
## Server key pair
|
|
|
|
`hbbs` generates `/var/lib/rustdesk/id_ed25519` (private) and `id_ed25519.pub` (public) on first boot. The public key is the fingerprint clients must trust.
|
|
|
|
Mirror after first deploy / after any intentional rotation. Read the key with
|
|
`fileb://` so it never lands in process argv (`ps`/`/proc`), shell history, or the
|
|
terminal (which SSM session logging would capture):
|
|
|
|
```bash
|
|
sudo aws secretsmanager put-secret-value \
|
|
--secret-id rustdesk/server-key-pair \
|
|
--secret-string fileb:///var/lib/rustdesk/id_ed25519 \
|
|
--region us-east-1
|
|
```
|
|
|
|
Run this from an environment that holds `secretsmanager:PutSecretValue` — the
|
|
instance role only has `GetSecretValue`, so either configure operator credentials
|
|
on the box first, or pull the key off the host over SSM (without echoing it) and
|
|
push it from your workstation. Never `cat` the private key to the terminal.
|
|
|
|
To **rotate** the key (forces all clients to re-trust): stop the containers, delete `id_ed25519*`, restart, re-mirror, redistribute the new public key.
|
|
|
|
## Restore from snapshot
|
|
|
|
1. Create a volume from the desired snapshot in `us-east-1a`.
|
|
2. Detach the current `rustdesk-data` volume (stop the instance first).
|
|
3. Attach the restored volume at `/dev/xvdf`, tag `Name=rustdesk-data`, start the instance.
|
|
4. Verify the key pair and DB are present and containers come up healthy.
|
|
|
|
## Pro license
|
|
|
|
Activated in the web console (`http://rustdesk.seahaven.com:21114`). Keep the key in `rustdesk/pro-license`.
|
|
|
|
## Logs
|
|
|
|
```bash
|
|
cd /opt/rustdesk && docker compose logs -f hbbs hbbr
|
|
```
|