Teamviewer analogue from VNC, SSH and superglue
The teamviewer is good for everyone, only for commercial purposes it’s not free, which you don’t get tired of reminding ... And in general, it’s not good to violate the license.
But the convenience of launching quick support is impressive - the client launches a small program, dictates tsiferki by phone and voila, we see his desktop. No VPN, no port forwarding and other pre-settings. Is it convenient?
VNC is quite suitable as a free analogue, with a call-back connection is quite acceptable, but only when there are many clients and the computer to which more than one problem clings too (although more solvable). I personally like the idea of teamviewer more. And if you like, why not make your implementation ...
')
Immediately make a reservation, the proposed solution, not even a solution at all, the implementation of the idea was made “to try,” but it proved its efficiency, and improvements and convenience can be completed in the course of time.
So, we take winvnc (tightvnc) as a basis, fasten a reverse SSH tunnel to it, and define the client, for example, by the port number. We will need:
OpenSSH server (on Linux, for example), web-server (with php in my case).
The client will use its own winvnc (I took from the tightvnc-portable kit) and the console client SSH plink from the Putty package.
In the alpha version of our remote support client, there will not be anything superfluous (and there will not be much more than that too), and TZ. for the server it will look something like this:
For client:
When started, the client should request from the server information about the tunnel.
Run winvnc with predefined settings
Raise the SSH tunnel with the obtained settings.
Let's start:
I will not go into the issues of running apache2 + php + OpenSSH, suppose that all this already exists.
Add a vnc user:
It is necessary to redefine the shell by default, otherwise someone smart can log in to the server.
Assign a password:
Any password, it will still lie somewhere in the clear.
In sshd_config (/ etc / ssh / sshd_config), we allow opening ports on all network interfaces by adding the option:
Without it, the tunnel will open at the address 127.0.0.1 (from the server) and without additional shamanism it cannot be used remotely. It remains to restart OpenSSH
It was thought up to transfer the settings to the client in the form of a cmd script that will launch a plink and notify the client about the magic dial that you need to report. This will be done by a PHP script (or what will be convenient) of the form:
And add permissions for the firewall:
Now we are going to build the package for the client. It will include:
winvnc (again, I took from the package tightVNC portable ) and the necessary libraries
putty plink
wget for windows (binaries and dependencies)
reg-files settings for winvnc and settings for plink. The latter really wants an approved SSH key in the registry and there is no way to add it interactively.
To get the cherished pieces of the registry, run Putty to cling to our SSH server, accept the key and export the registry:
We do the same with the winvnc settings: we run on a benchtop computer,
in the settings we set:
Apply, close and export:
Add a vb script that will display a message box with the specified text:
mb.vbs:
And the most important script that will connect everything:
runme.cmd:
winvnc is broken in it (is it suddenly already working?),
import the registry pieces,
run winvnc
Download the script and if downloaded - run it.
It remains to add all of the above in one folder and pack it into the SFX archive, with the launch of this script after unpacking: for WinRAR SFX, something like this:
and you can give to the client. At startup, the archive will be quietly and quietly unpacked, the runme.cmd script will run, which will configure winvnc, plink, download the tunnel startup script, launch it and notify the client of the port number.
As in the case of teamviewer, the client reports it, and you can connect (already to our SSH server, with the specified port number)
As a result, we have:
Now for future plans:
But the convenience of launching quick support is impressive - the client launches a small program, dictates tsiferki by phone and voila, we see his desktop. No VPN, no port forwarding and other pre-settings. Is it convenient?
VNC is quite suitable as a free analogue, with a call-back connection is quite acceptable, but only when there are many clients and the computer to which more than one problem clings too (although more solvable). I personally like the idea of teamviewer more. And if you like, why not make your implementation ...
')
Immediately make a reservation, the proposed solution, not even a solution at all, the implementation of the idea was made “to try,” but it proved its efficiency, and improvements and convenience can be completed in the course of time.
So, we take winvnc (tightvnc) as a basis, fasten a reverse SSH tunnel to it, and define the client, for example, by the port number. We will need:
OpenSSH server (on Linux, for example), web-server (with php in my case).
The client will use its own winvnc (I took from the tightvnc-portable kit) and the console client SSH plink from the Putty package.
In the alpha version of our remote support client, there will not be anything superfluous (and there will not be much more than that too), and TZ. for the server it will look something like this:
- On the server, there must be a certain user without rights, without the right to log in to the system, but with the ability to raise reverse tunnels. Straight tunnels should also be limited.
- The server somehow has to inform the client about the tunnel, the address, the free port from a certain range.
For client:
When started, the client should request from the server information about the tunnel.
Run winvnc with predefined settings
Raise the SSH tunnel with the obtained settings.
Let's start:
I will not go into the issues of running apache2 + php + OpenSSH, suppose that all this already exists.
Add a vnc user:
$ sudo useradd -M -s /bin/false vnc It is necessary to redefine the shell by default, otherwise someone smart can log in to the server.
Assign a password:
$ sudo passwd vnc Any password, it will still lie somewhere in the clear.
In sshd_config (/ etc / ssh / sshd_config), we allow opening ports on all network interfaces by adding the option:
GatewayPorts=yes Without it, the tunnel will open at the address 127.0.0.1 (from the server) and without additional shamanism it cannot be used remotely. It remains to restart OpenSSH
$ sudo service ssh restartIt was thought up to transfer the settings to the client in the form of a cmd script that will launch a plink and notify the client about the magic dial that you need to report. This will be done by a PHP script (or what will be convenient) of the form:
<?php $server = 'mysshserver.com'; // OpenSSH $user = 'vnc'; // $password= '123'; // $ssh_port=22; // SSH $vnc_port=11111; // VNC- $port_start = 40000; // $port_end = 50000; $ports = NULL; // $r = exec("netstat -lnt4 | tail -n +3 | awk 'BEGIN{FS=\"[: ]+\"}{print $5;}' | sort -n", $ports); // do { $port = rand($port_start, $port_end); if(!in_array($port, $ports)) break; } while (1); // cmd- header("Content-type: text/plain;"); echo "@echo off\r\n"; echo "title Port number is: $port\r\n"; echo "start /MIN cscript mb.vbs \"Port number is: $port\"\r\n"; echo "plink.exe -N -R $port:localhost:$vnc_port -P $ssh_port -pw $password -l $user -batch $server \r\n" ?> And add permissions for the firewall:
# iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT # vnc itpables -A OUTPUT -m owner --uid-owner `id -u vnc` -j REJECT # 40000-50000 itpables -A INPUT -p tcp --dport 40000:50000 -j ACCEPT ( -, SSH, HTTP -, ): itpables -P INPUT DROP itpables -A INPUT -p tcp —dport 22 -j ACCEPT itpables -A INPUT -p tcp —dport 80 -j ACCEPT Now we are going to build the package for the client. It will include:
winvnc (again, I took from the package tightVNC portable ) and the necessary libraries
putty plink
wget for windows (binaries and dependencies)
reg-files settings for winvnc and settings for plink. The latter really wants an approved SSH key in the registry and there is no way to add it interactively.
To get the cherished pieces of the registry, run Putty to cling to our SSH server, accept the key and export the registry:
reg export HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys keys.reg We do the same with the winvnc settings: we run on a benchtop computer,
in the settings we set:
- Password or empty, to taste, on the Server tab,
- in the same place we set the port number I put 11111 (used in only PHP-script).
- On the Administration tab, we allow loopback connections, in the case of an empty password, we allow them to be used.
- Well, turn off the HTTP server, in our case it is not used.
Apply, close and export:
reg export HKEY_CURRENT_USER\Software\ORL\WinVNC3 winvnc.reg Add a vb script that will display a message box with the specified text:
mb.vbs:
Set objArgs = WScript.Arguments messageText = objArgs(0) MsgBox messageText And the most important script that will connect everything:
runme.cmd:
winvnc.exe -kill reg import host-key.reg reg import winvnc.reg start winvnc.exe -run wget http://mysshserver.com/script.php -O tunnel.cmd && tunnel.cmd winvnc.exe -kill winvnc is broken in it (is it suddenly already working?),
import the registry pieces,
run winvnc
Download the script and if downloaded - run it.
It remains to add all of the above in one folder and pack it into the SFX archive, with the launch of this script after unpacking: for WinRAR SFX, something like this:
Silent=1 Path=%TEMP%\support SavePath Setup=%TEMP%\support\runme.cmd and you can give to the client. At startup, the archive will be quietly and quietly unpacked, the runme.cmd script will run, which will configure winvnc, plink, download the tunnel startup script, launch it and notify the client of the port number.
As in the case of teamviewer, the client reports it, and you can connect (already to our SSH server, with the specified port number)
As a result, we have:
- Client can sit behind NAT
- VNC Viewer can also be behind NAT
- The only thing needed to connect to the client is the port number that the client dictates.
Now for future plans:
- Remove heavy wget and generally rewrite all scripts on VBS
- Make a web-based interface for tracking connected clients and the ability to download a VNC file for quick connection.
- What else?
Source: https://habr.com/ru/post/137723/
All Articles