-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Open
Description
Description
I've discovered what appears to be a logic issue in the hbbs (RustDesk ID/Rendezvous Server) implementation that makes it impossible for clients to connect when the server is started without an explicit key.
The Problem
When analyzing the code, I found the following behavior:
- In
src/main.rs, if no-k(key) argument is provided, the server defaults to"-":
RendezvousServer::start(port, serial, &get_arg_or("key", "-".to_owned()), rmem)?;- In
src/rendezvous_server.rs, theget_server_skfunction treats"-"as a special value and generates a new random key pair:
if key.is_empty() || key == "-" || key == "_" {
let (pk, sk) = crate::common::gen_sk(0);
out_sk = sk;
if !key.is_empty() { // Since key is "-", this is true
key = pk; // Replaces "-" with newly generated public key
}
}- Later in
handle_punch_hole_request, the server checks if the client's key matches:
if !key.is_empty() && ph.licence_key != key {
// Returns LICENSE_MISMATCH error
}The Issue
This creates a situation where:
- If you start the server without specifying a key, it generates a random key
- Clients have no way to know this randomly generated key
- All client connections fail with
LICENSE_MISMATCH
The only way to disable key checking would be to have an empty key string, but that's impossible because:
- Empty input → replaced with
"-"in main.rs "-"→ generates new random key- Random key is never empty → key checking is always enabled
Question
Is this the intended behavior? If so, how are self-hosted servers supposed to work when no key is specified?
It seems like either:
- The server should not generate a random key when
"-"is provided (just keep it as"-"or empty) - Or there should be a way to truly disable key checking
- Or the generated key should be communicated to clients somehow
Am I misunderstanding the intended logic here? How is this supposed to work for self-hosted deployments?
Environment
- RustDesk Server (hbbs)
- Self-hosted deployment
Thank you for clarifying this behavior!
Metadata
Metadata
Assignees
Labels
No labels