The Remote Control tool landscape is a bit crazy these days. As someone that often controls computers remotely, I’m always looking for better and more useful options in this space. I’ve even spoken about the lack of an open-source peer-to-peer remote access tool. Well, no longer is that the case. RustDesk is a remote access tool modeled much like TeamViewer. In fact, if you’ve used TeamViewer, RustDesk will seem very familiar. With the 1.1.9 release of this tool I wanted to take a look at the good and bad.

Running RuskDesk is very easy. It supports a bunch of Operating Systems, but if you’re on Windows, it’s a matter of downloading the appropriate client for your operating system, unzipping it and running it. You’d do this for the two (or more computers) you might have. Each of the computers will connect out to RustDesk on the Internet and get what’s called an ID which is expressed as a nine or longer digit number. An example ID of a computer is below expressed as “140 521 149.” When you have RustDesk running on two different computers, get the ID of the other one (such as “266 054 633” below), click connect and supply a password. That password is fund under the “Password” field on the target computer and is automatically generated. Between two Windows computers, this would be it, connecting back and forth.

To say this might be a challenge for RustDesk is an understatement. To generate the ID and facilitate that connection, RustDesk has to run a server. This server would probably add up in cost for them if the tool was in widespread use. For that reason, RustDesk also as a self-hosted server option that you can run on your computers. This opens up all sorts of options for running the tool locally outside of Internet access and controlling the way you want to tool to be used. It also introduces the need for the work of securing the server, especially if it’s open to the Internet by way of ports.

My experience running the server both on Windows and Linux (docker) has been thus far positive. The process of installing is fairly straightforward, and finding the necessary “key” needed to enable encryption is not so painful. I do notice clients that see configuration changes don’t always reflect the key change immediately – but that’s minor. When a connection is established, the process appears smooth and useful. The tool supports multiple monitors, which was an important feature for me. Much like other similar tools, you can transfer files, chat and enable some other features such as tunneling). I see this list of features changing over time to include things other tools do well – such as drag and drop file transfer or printing.

This is all to say that RustDesk is a little, uhm, Rust-y (forgive the pun) in a few areas. These may be show-stoppers depending on the type of tools and options you expect. Here are some of the things I’d like to see added to the tool that would signal maturity:

1. Support some kind of address book or a web client. Perhaps the Biggest missing feature of RustDesk free is the means of organizing client access by way of a list, folder structure or other management ability. In the client application there is even a “Login” section that implies a past tool that could have been used to organize hosts (such as how TeamViewer does. This feature has been disabled and may be reserved for a “Pro” version in the future. Some tools, such as ConnectWise Control implement a web-based tool to organize access to hosts. Currently RustDesk offers a web tool that does not support TLS, nor does it implement a host list.
2. Support Two Factor. A glaring miss for this tool, but having some means of ether per-host or in the previously mentioned host manager for two-factor authentication via an authenticator application. Security must be primary and ongoing for a too like this to gain wider acceptance.
3. Improve Transparency on Encryption. There does appear to be encryption between client and host and the docker implementation includes the ability to for encryption with an environment variable, but this encryption is not as visible as it could be. There needs to be a review of what portion of the connection is encryption and not or be more transparent about connections.
4. Ports, Ports, Ports. Currently, RustDesk uses a mishmash of standard ports that include 21115, 21116, 21117, 21118, 21119 and previously 21114 (for the now missing login server). This is just a mess. Starting with the most obvious issue with this: No reasonably protected stateful network is going to allow these higher order ports OUT of the network. This means no remote access to machines from coffee shops, hotels and restaurants when you might want the tool to be more universal. What I expect this to morph into is the use of one single external port that can be the encrypted 443 from authentication to connection. Period. It has to get here just like other popular tools to be more widely accepted.
5. Better Client pre-config. Allowing the use of either a local .INI file or other means of pre-configuring some of the client settings (possibly even adding hosts to a pre-built address book) should replace the current “rename the .exe” file that is currently in place. While renaming the EXE is nifty, it doesn’t scale well on different platforms or to keys that have special characters or, well, just adding more than a couple configuration options.

As it turns out, I like this tool enough to self-host it locally and se where it goes. I’m always interested in the process of how software starts from useful and gets molded into something kick-ass an fantastic. RustDesk surely has that potential and my hope is it gets there. If the maintainer of the project reads this, I’m offering my help to to improve documentation or anything else I can do. Contact me.