SSH instead of VPN

Surely, many system administrators were faced with a situation where the number of remote users in the company became more than one so much that the thoughts of a normal VPN instead of nat didn’t give peace in a hurry and became an obsession. And I am sure everyone frowned when he understood that the users had to explain what to press and where. And in my personal case there is also a position regarding the wards: “they should not even think about how it works.”

At first there were not many. Only a couple of people walked rdp to their desktop from home and I was in no hurry to implement the solution, but when the 1C server moved from the head office to my network and a whole army of accountants and other figures appeared, the hair on my head began to move from the prospect of flooding the firewall rules with strings type dst-nat.

For some reason, an alternative to my solution, I only saw a VPN (in one form or another), which meant that I would need to write instructions to create a connection on the user's computer. From here, the prospect of answering questions like: “what did I do wrong?”, Because on every version of Windows this is not done in exactly the same way. Plus, it would be necessary to explain how to connect to the right computer - again, to create these labels and all that. And by the way, a person could go to the village to visit his grandfather somewhere where setting up someone else’s computer is not welcome. Therefore, it seemed to me that just as I had planned, it would be most convenient.
')
The very idea of ​​what and how to do was born a long time ago and, in principle, everything was clear.
The task is simple: connect the user to the desktop on a working computer (or any other) in one click. Those. The user connects the flash drive on which there is a certain exe. Runs this exe, enters the password and voila - it is on the working computer.

Some lyrics, if you will.

I am sure everyone watched a great movie "Mind Games". Remember the phrase of the doctor in the clinic: "What could be worse for a schizophrenic than to realize that he is schizophrenic?"

Projecting onto myself I can paraphrase: “What could be worse for a programmer than to realize that he is a system administrator?”. This is me to the fact that for more than 10 years of adminstva I have grown stupid. What I would have written in a couple of days would have done a week now and I’m sure that I could have done better.

By and large, nothing complicated. We take source libssh2, openssl and zlib and we fasten them to our project. It is the source or static libraries because we don’t want us to have more than one file at the output. If you have to put another dll solution next to the exe, it will lose its “elegance”.

The program creates ssh-tunnel to the remote computer and listens on the local address ala localhost. It starts mstsc and connects to localhost (actually with the remote computer).

I had to suffer with openssl. I haven't seen such scanty documentation yet. Examples from the wiki on the project site work, but do not explain anything. The description of the functions comes down to their purpose. Yes, and to spit, because libssh is going, but I need to store the connection settings in the exe file, read in clear text, and these are passwords and keys. For this, having played a little with various options of functions, I still encrypted the data and put it at the end of the exe.

In fact, it turned out to be an analogue of plink from putty, but with the ability to clone itself while preserving the connection parameters and executing some command on the user's computer. For example:

rlink --saddr=example.host.com --sport=2222 --lport=1234 --raddr=pc.localdomain --rport=3389 --user=andrey --cmd="mstsc /v:localhost:1234" 

With this set of arguments, the program will create a localhost: 1234 → pc.localdomain: 3389 tunnel and start the rdp client and wait for it to complete. Since the argument --pass is omitted here, the password will be requested interactively.



You can add the -a key, then the output will be a ready-made exe with the name rlink- username .exe and ready to run without entering any arguments on the command line.



By default, keys for encrypting settings are generated automatically, but you can set a secret word using the - key and encrypt based on it. Then when you start the program, the first thing you will be asked for a password to decrypt the arguments.



Of course, in order for all this to work, there remains one more small detail: create a user on the ssh server. But that's another story. And you can still write a script to bring to the automatics the creation of a user and the generation of a ready-made exe for him, which I will do in the near future.

Feel the program here .

Sorry for the confusion and thank you for your attention.