rustdesk-server icon indicating copy to clipboard operation
rustdesk-server copied to clipboard

hbbs server generates random key when no key is specified, making it impossible for clients to connect

Open dmikushin opened this issue 5 months ago • 4 comments

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:

  1. 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)?;
  1. In src/rendezvous_server.rs, the get_server_sk function 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
    }
}
  1. 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:

  1. The server should not generate a random key when "-" is provided (just keep it as "-" or empty)
  2. Or there should be a way to truly disable key checking
  3. 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!

dmikushin avatar Sep 16 '25 06:09 dmikushin

I also have this issue.

Can't even find a workaround for this, or if there's one, i have yet to understand how to proceed.

For now, i'm fine with applying manual fixes, if there's any.

dgva avatar Sep 26 '25 13:09 dgva

So the workaround is to use the key. Just generate a fairly complex key with an openssl command and use it for the server and all your clients.

Some RustDesk self-hosting guides also suggest to use the key.

In general terms, after some thinking I also recommend to use key. Key-less default setup smells a security issue. First of all, it means the RustDesk's own default server code is not the same as the server that they publish here. Secondly, we can't review how the key-less setup is meant to work. The devs should come over and explain what's going on - until then always use the key.

dmikushin avatar Sep 26 '25 14:09 dmikushin

@dmikushin What type of key it expects with -k flag? What is the type and length configuration for this key? And is there any documentation or guide on all the possible flags for hbbs and hbbr with their defaults somewhere? And any idea if all the flags are interchangeable with environment variables?

uGiFarukh avatar Sep 29 '25 10:09 uGiFarukh

I don't know about the docs, but I used this:

openssl rand -base64 32 | tr -d "=+/\n"

This is a method often used to create API secrets.

dmikushin avatar Sep 29 '25 11:09 dmikushin