When the movies show how an epidemic of a terrible virus breaks out on Earth, people there mainly need stew and cartridges. When this fantasy came true, it turned out that what was needed most was toilet paper and remote workplaces. And if everything is clear with the first, the second point raises questions from the point of view of security and software choice. When a ready-made solution doesn't work, you need to start assembling your bike.
Services that can be used to organize remote connection of employees usually work through their servers. The connection is almost always slower than direct connections, and the security of such services is also a big question. Most often, the architecture of these solutions is built around the implementation of VNC (Virtual Network Computing). The system is based on the RFB (Remote FrameBuffer) protocol. The control is arranged as follows: keystrokes and mouse movements are transmitted from one computer to another, and the contents of the screen are relayed over the network. VNC itself does not encrypt transmitted data. If increased security is required, the session can be established over SSL, SSH or VPN tunnels, which complicates the task somewhat.
On public services, all connections are established through a server that issues client IDs, connecting them either through VPN directly to each other, or through their own channel. Of course, you can set up your VPN server, configure VPN and enterprise LAN routing, and connect employees using direct IP addresses. In this case, the client needs, in addition to the login, password and connection address, to transfer the VPN client and data for authorization. For some users, all this is complicated, and this, in turn, will complicate support.
Forwarding ports to local PCs is also not an option. This is unsafe, and you get tortured to configure routing when there are more than two clients. Linux has a wonderful client Remmina, which allows you to forward RDP / VNC sessions over an SSH connection without additional clients. On Windows, you can SSH tunnels through client applications that need to be configured on remote user machines. The SSH client "out of the box" is available only in Windows 10, but what about the users of the seven and eight? And for Windows 10 you will have to write a batch file, and more than one. All this does not add points to standard solutions. But you can always come up with something non-standard. What we are going to do right now.
Formulation of the problem
So, our task will be the following. Connect user by RDP (as it turned out, this is much more familiar to most of them). The biggest advantage of RDP over VNC is speed. RDP is faster because it only redraws the changed portion of the screen on the client side, which means less data is transferred. The connection must be secure. The connection should be performed with minimal settings and should not require any additional actions from the user.
What will Google say?
In general, the task is not new, and there are quite a few implementations of building an SSH tunnel. On Google you can find Putty based solutions or options for Windows 10… We love our users and our nerves too. This means that you need to give them a tool that does not need to be configured and that will work reliably.
In other words, the solution must meet the following requirements:
- simplicity for the user;
- ease of support;
- simple and straightforward preparation and configuration of "server parts".
The solution will be based on RDP over SSH technology. Technically, we will organize it like this:
- SSH client for organizing a tunnel with port forwarding to the target PC of the connection;
- automatic start of an RDP session without additional input of connection parameters.
The system should be easily embeddable and there should be a client for advanced users (optional).
Preparing the server side
We will not consider simple things like setting up an RDP or SSH server. There are a lot of instructions on the Internet, but our volume is limited, and you don't want to overload the article. Also, I will not go into detail on how to implement receiving data from Kerio Control: on the project page you can find ready code…
First thing we need to do is allow RDP connections on client machines on the local network. If it implements centralized management like Active Directory, you're in luck. Allow connection to RDP in group policies. If not, walk around the workstations with our feet and allow RDP on the target local machines. Let's not forget about firewalls.
In the second step, we need an SSH server accessible from the Internet. Any solution will technically work. I used a VPS with Debian 10 (one of my friends used to set up such a server even on a router, which is unsafe). Further, it is worth dividing the solutions into several versions, the specific implementation depends on how the receipt of data for user authorization is organized.
Initially, we used Kerio with user authorization via AD.
The client connected via SSH, forwarded the port to the Kerio Control Server API, then connected to it, searched for the specified parameters (username or surname of the employee), looked for the IP of the local PC. Then he broke off the SSH connection and established a new one with port forwarding to the found IP, to the RDP port (3389), after which the RDP session was raised using standard Windows tools with the transfer of connection parameters.
This solution worked pretty quickly, but this was not enough for us, and we divided it into two parts. The server script began to work on the SSH server and from time to time go to Kerio for information. The client part connected to the server via SFTP, looked for the necessary data, formatted in JSON, and made the connection. As a result, the speed of work has increased.
I recommend immediately setting up an OpenSSH server with key access and preparing RSA keys for authorization. To do this, you need to create a separate user and restrict him in rights, then give him the public part of the key. Below is a part
/ with the settings of these two users:
Match User sftp
# PasswordAuthentication yes
Match User user1
ForceCommand /usr/bin/cmatrix # Подойдет и любая другая заглушка (можно заморочиться и отправлять пользователя в песочный bash)
The first SFTP user is only allowed to connect to that very SFTP. The second is only for port forwarding. If you use Kerio to get user data, Active Directory or something else centralized, I recommend creating a separate account and restricting it in rights just in case.
So, we have approached the realization of the intended goal. We will write the whole thing in Python 3.8. Firstly, it is a multiplatform language, and secondly, it is assembled quickly and easily. Thirdly, it is easy to learn, and fourthly, it includes a huge number of libraries.