Make sure to have only valid Windows filename characters in your public key. I had problems first too because I had an "/" in my public key. If that's the case for you:

1. delete id_ed25519.pub und id_ed25519 in ~/rustdesk/hbbs
2. restart container or what kind of installation you have
3. repeat until you have only valid characters for Windows filenames in your public key

My public key only has regular characters in it APART from the = equals sign at the end... is this OK for Windows?

'rustdesk-host=rustdesk.mydomain.uk,key=KjPK1Q7t3xxxxxxxxxxxxxxxxxxxxxxmi7DlwQ=.exe'

If the xxxx are normal characters, it looks finde for me. The "=" is no problem.

Forbidden characters are:
~ “ # % & * : < > ? / \ { | }

It worked for me but I had to add --silent-install when running the renamed exe. I agree it's a very cumbersome way of configuring the app.

Yes, some sort of generator is my idea, too. It would be great for Mac, Win and Linux at least.
I can already build the client for Linux but I'm not getting the .deb-file as the build.py-script is not working for me yet.
Cross-compiling from Linux to Mac and Win would be ideal, but I'm not sure if this will work.
Do you know how the release-files (deb/AppImage, dmg, exe) are created?

The filename is fine if you use the files yourself, I agree. I want to use the client to support the users of my software and the filename-approach does not work for me in this case. A cfg-file makes it unnecessarily complicated, it's hard to explain via phone. A single .exe(/.dmg/.AppImage-file) just has the lowest friction.

In your case it would not be necessary to explain over the phone, you can use winrar, winzip or 7zip to generate an executable with the rustdesk exe, along with the configuration file.
It's the same logic as the pfSense OpenVPN installer, for example, which is generated at runtime by pfSense itself by zipping the ovpn configuration file + openvpn installer.

It would be great if there was some sort of build tool that allows for the creation of a client app that embeds the relevant key/host details.

While testing, I have opted to use a custom URL shortener to keep a simple URL for end users to download the client.

Using the filename method causes issues when an end user is unaware that they have already downloaded the file. Because most browsers will simply append something to the end of the filename, it breaks the key.

If you store on your own web server with apache, it would be simple, just create a https://multiti.com.br/rustdesk.php for example and this .php page forces you to download the file with the full extension with a redirect to for example https://multiti.com.br/files/rustdesk-host=MY.DOMAIN,key=MY-PUBLIC-KEY=.exe
The content of rustdesk.php could be:

There is no need for PHP code. You could do it with a simple Apache redirect. In my case, I have a personal URL shortener that turns https://mydomain.com/remote into https://files.mydomain.com/files/rustdesk-host=MY.DOMAIN,key=MY-PUBLIC-KEY=.exe

But that doesn't change the problem that the key gets mangled when it is accidentally downloaded a second time.

It also offers no solution for Mac.

The filename is fine if you use the files yourself, I agree. I want to use the client to support the users of my software and the filename-approach does not work for me in this case. A cfg-file makes it unnecessarily complicated, it's hard to explain via phone. A single .exe(/.dmg/.AppImage-file) just has the lowest friction.

In your case it would not be necessary to explain over the phone, you can use winrar, winzip or 7zip to generate an executable with the rustdesk exe, along with the configuration file. It's the same logic as the pfSense OpenVPN installer, for example, which is generated at runtime by pfSense itself by zipping the ovpn configuration file + openvpn installer.

Why do you need a cfg file? You can simply 7zip the "long name exe" generating a generic my_rustdesk.exe and execute rustdesk-host=MY.DOMAIN,key=MY-PUBLIC-KEY=.exe from it. If it works the MS Windows part is solved with this workaround.

rustdesk/rustdesk-server@848b5ae

That's some hyper speed response :)

In old times, it was not complicated to add custom data at the end of exe, and exe was able to access it. If that technique is feasible with modern tools that cold be way to solve an issue.

In that case user could start RustDesk client, set it up, including host, port, key and whatever else) and then click option to produce new exe with all that settings attached. New exe, when run, would red settings from itself and reconfigure.

Honestly, a file called rustdesk.cfg alongside the .exe would work. That way, I can get my client to download both files and run the .exe so it picks up the config.

Remove installed version and use self executing exe. That is only way that standalone renamed to connect to self hosted server would work.

Check #2152

@pedjas Then what is needed now is probably an embedded "local config" cleanup or "uninstall" button.
To actually remove rustdesk local service configuration we need to be... admin user.
If the client is not an admin user then we need a proper option for that to work.
For example a "fully portable" instance of rustdesk is one way.
If the user is admin then we need to cleanup any:
RustDesk.toml
and
RustDesk2.toml

(on windows)
from the user roaming appdata folder ie:
%AppData%\Roaming\RustDesk\config

And also local services roaming profile which is at under the windows folder (for example):
C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\

About the serf extracting exe it's pretty simple to do.
The other issue is the cleanup.
If the rustdesk project or anyone else can help to write a cleanup and uninstaller script it would help a lot.
The uninstaller can be based on the next script:
https://github.com/techahold/rustdeskinstall/blob/master/WindowsAgentAIOInstall.ps1

which works great on windows 10 and up.

I have also found another issue with the file naming.
There should be an option to use another parameter in the file name after a ",".
Currently the only way it works is if the file name is constructed with only the host=hostname,key=key.exe
I would have expected for it to support also host=hostname,key=key,company=x,otherkey=value.exe

@pedjas Then what is needed now is probably an embedded "local config" cleanup or "uninstall" button. To actually remove rustdesk local service configuration we need to be... admin user. If the client is not an admin user then we need a proper option for that to work. For example a "fully portable" instance of rustdesk is one way. If the user is admin then we need to cleanup any: RustDesk.toml and RustDesk2.toml

Cleanup is advanced and I believe not necessary. If config stuff is saved at the same place where standalone EXE is, and that is out of system folders then no special privileges are needed to create or delete them.

I am pretty sure, if resdeks.exe standalone does not save config into %appdata% directory but at the directory where exe is, problems would be resolved.

Change in code should be fairly simple as described in #2127

@pedjas I believe that there is a site which scans the files with a set of AV software.
As far as I can tell MS Defender and couple others are OK with it.
I would assume that some specific AV recognize rustdesk as spyware but it's another matter and should be opened in another issue.

That’s an interesting solution!

That's a PERFECT solution! (yes if DNSSEC)

So, natively/out-of-the-box, RustDesk will try to resolve _hbbs._tcp.{local_domain_name} and hbbs_key.{local_domain_name}?

@coucoy Is this working on a public domain too? That would be great!

Without the client storing the public key, there is no way of identitying if a MITM attack has caused a false key to be returned. The other systems that offer public key exchange have a trusted method of exchanging keys via an intermediate server.

Of course you are right. Silly me :-) Thanks for the clarification.

This is 100% working solution on current day

What problem are you offering this as a solution to? It appears unrelated to the issue being discussed.

This is 100% working solution on current day
What problem are you offering this as a solution to? It appears unrelated to the issue being discussed.

Situation:
self server on debian with real IP with key auth only
client in localnet to client on localnet - connect sucess
client in localnet to client on internet - connect is broken
client on internet to client in localnet - connect sucess

after set this settings all problem is away

P.S. no active firewall is present to outgoing traffic...

Situation

That is not what this discussion is about. As the OP states in their opening sentence, we are fully aware of the filename-based method of sharing the key with a client. This discussion was started as a way of discussing possible alternatives and methods that are available for non-Windows clients.