Despite -k _ option, connection without key still possible

[rucksman]

I am testing rustdesk and use the docker images. For both containers (hbbs and hbbr) I enabled the "-k _" option like so:

command: hbbs -r my.domain.com:21117 -k _
command: hbbr -k _

Then I downloaded the portable Windows client and started it. I changed the "ID Server", and without entering the key the green status lights up, connection is obviously made. What am I doing wrong here? Or do I misinterpret the "-k _" option?

[xVlmRx]

Hello I have a similar problem

I tried to prescribe in docker-compose.yml for services

command: hbbs -r <my_domain>:21117 -k _
command: hbbr -k _

Similarly, I raised the s6 container and prescribed -"ENCRYPTED_ONLY=1"

After that, for verification, either did not specify or specified the wrong public key in the client settings. Anyway, the client connected to the server and then also successfully established a connection to the managed machine.

[christiantakle]

Same @xVlmRx using the docker-compose example using the example from the docs.

(cannot link so inlining)

version: '3'

services:
  rustdesk-server:
    container_name: rustdesk-server
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21117:21117
      - 21118:21118
      - 21119:21119
    image: rustdesk/rustdesk-server-s6:latest
    environment:
      - "RELAY=rustdesk.example.com:21117"
      - "ENCRYPTED_ONLY=1"
      - "DB_URL=/db/db_v2.sqlite3"
    volumes:
      - ./db:/db
    restart: unless-stopped
    secrets:
      - key_pub
      - key_priv

secrets:
  key_pub:
    file: secrets/id_ed25519.pub
  key_priv:
    file: secrets/id_ed25519     

[paspo]

I just finished trying to reproduce this issue:

• freshly installed debian 11 VM
• latest docker form official repo
• docker compose from the above reply (I only changed RELAY=rustdesk.example.com:21117 to use the IP address of the VM)
• generated a new keypair
• 2 spare win10 VM, on different networks
• set ID server with the IP of the server VM
• if I dont's set a key (on one side or both), no connection
• if I set the wrong key (on one side or both), no connection
• only if I set the correct key on both sides, I have a connection so this works as expected, and this also means I can't reproduce the issue.

You have different results, so clearly there's something different between your setup and mine.

[paspo]

Just to establish some common ground: you have to start a connection between two peers to check if the key is valid, the "ready" state in the bottom of the client windows is indicating only the connection to a server (AKA your client saying hello to the server) not the server validating your key.

[christiantakle]

• Linux takle--pi4 6.0.8-2-MANJARO-ARM-RPI #1 SMP PREEMPT Sat Nov 12 22:43:17 UTC 2022 aarch64 GNU/Linux

• docker --version => Docker version 20.10.21, build baeda1f82a

• docker compose from the above reply (use a zeroconf domain like hostname.local)

• used docker run --rm --entrypoint /usr/bin/rustdesk-utils rustdesk/rustdesk-server-s6:latest genkeypair and manually put the the output into the respective files

• set ID server to <ip>::21116

• connecting from ipad to macbook, ipad to linux laptop. Doesn't matter if I have Key input filled or not or have a typo. Its successful when accepting the incoming connection or knowing the password of the client.

So the difference is a local-network only vs different networks and is that expected?

update: changed RELAY in the docker-compose file to use explicit the ip + docker compose --file containers/rustdesk/docker-compose.yml up --detach --force-recreate for completeness. The result is the same.

[paspo]

I don't have a raspberry PI 4, so the tests can't be 100% representative. Here's what I did this time:

• raspberry PI (Raspberry Pi 3 Model B Plus Rev 1.3)
• Raspbian GNU/Linux 11 (bullseye)
• docker 20.10.5+dfsg1 from repo
• usual docker-compose.yaml from your above post, with the rpi IP address as RELAY
• newly generated secrets
• VM1: Win10pro in a different subnet (192.168.122.167/24)
• VM2: Win10pro in another different subnet (192.168.2.57/24)
• both VM1 and VM2 can ping RaspberryPI (192.168.254.210/24)
• for how the firewall rules are setup, VM1 can ping VM2 but not vice-versa

It turns out I said something wrong in my previous reply, let me fix that:

• if I don't set a key on the side that is starting the connection, I get no connection because of "mismatching key", regardless of the key setting on the "receiving" side
• same thing if I use an invalid key or a different key
• for the connection to work, we need the correct server and key on the "requesting" side and the correct server on the "target" side. So you need the key only when starting a connection.

Honestly I never tough of testing this behavior, I always supposed the key was needed both sides. @rustdesk any comment on that? Is that by design?

This behavior is true for both x86-64 and armv7.

[robotex82]

We are experiencing the same problem using the latest docker image on synology. Is there any progress regarding this issue?

[lonix1]

Same problem here. I tried the s6 docker image with ENCRYPTED_ONLY=1, and the normal docker image with -k _.

[glitch452]

@paspo Re:

• for the connection to work, we need the correct server and key on the "requesting" side and the correct server on the "target" side. So you need the key only when starting a connection.

The documentation would seem to indicate that this is by design, although it's not necessarily worded in the clearest way 🤔:

... If you want to prohibit users without the key from establishing non-encrypted connections, please add the -k _ parameter when running hbbs and hbbr ...

But I've also run into situations where I wasn't able to establish a connection unless both clients had the key.

[RR-T]

I seem to have the same issue as posted above, my docker-compose looks like the following:

version: '3'

services:
  rustdesk-server:
    container_name: rustdesk-server
    image: rustdesk/rustdesk-server:latest
    environment:
      - "ENCRYPTED_ONLY=1"
    command: hbbs -r rustdesk.domain.xyz:21117
    volumes:
      - /media/data-ssd/rustdesk/data:/root
    depends_on:
      - rustdesk-relay
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    networks:
      rustdesknet:

  rustdesk-relay:
    container_name: rustdesk-relay
    image: rustdesk/rustdesk-server:latest
    environment:
      - "ENCRYPTED_ONLY=1"
    command: hbbr
    volumes:
      - /media/data-ssd/rustdesk/data:/root
    ports:
      - "21117:21117"
      - "21119:21119"
    networks:
        rustdesknet:

networks:
  rustdesknet:

However I am able to initiate a connection without a key on either side, and of course get the following:

[Kurgan-]

Yes, i have the same issue.

Setting the environment variable "ENCRYPTED_ONLY=1" does absolutely nothing.

If I specify -k "my private key" (where the key is the text extracted from the file id_ed25519) for both hbbs and hbbr, then it actually refuses connections with the wrong key.

(I'm running hbbs and hbbr not in docker but as normal executables on my server)

It seems security is not a a priority in Rustdesk.

[paspo]

environment:

• "ENCRYPTED_ONLY=1"

This option is valid only in the rustdesk/rustdesk-server-s6 docker image. If you set this to "1", the -k _ parameter will be added to the command line. See https://github.com/rustdesk/rustdesk-server/blob/79f0eb497b4adaaadb51f6ba3a58978846fa5318/docker/rootfs/etc/s6-overlay/s6-rc.d/hbbs/run#L5

It has no effect on the binary itself or on the classic docker image (which only contains the binaries).

[Kurgan-]

Thanks for the clarification. I believe this should be the default behaviour anyway, since it's more secure.

[pviffx]

I can confirm this bug still exists, just tried on a Win11 with client 1.3.1