Introduction
If you’ve ever been in charge of a network you’ve definitely had the need for a secure remote connection. Maybe you just need to keep an eye on employees or kids. Doing so can be a hassle to some while crossing networks and subnets. On top of that, many businesses may have Internet but no DHCP to more protected machines. Many do this to network machines while keeping employees from surfing the Web. Whatever the case, Linux has many great tools to enable remote encrypted GUI administration. Even better, we will get everything we need for free for accessing a Linux or Windows client.
Requirements
You should have root privileges on the machine you wish to monitor from as well as on the clients. You are not required to have administrator rights on a Windows client if you can at least enable remote desktop. To follow this tutorial you can use virtual machines if you do not have physical clients to test on. As long as you have the rights above and an IP address you should be fine.
Legal disclaimer
While I’ve already mentioned legitimate purposes for this tutorial, it can be abused. The purpose of this writing is to help people network their own machines. Please use this information for legal monitoring of clients only!
Setting up our host
The first thing you should do is download the necessary packages with apt-get, if you’re on Debian or derivatives:
# apt-get install xrdp openssh-server
After that we need to do some configuration to make sure our ssh server runs correctly. In a terminal type “ssh-keygen” to create the rsa keys for encryption. You will see some ascii art go by and then it’s done. Most likely your rsa keys will be stored in /home//username/.ssh/ if you ever need to find them.
Now we can check to make sure everything is running.
$ netstat -antp Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6294/sshd tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 6230/xrdp-sesman tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 6227/xrdp
Running this netstat command we should see something like this. Obviously port 22 is our ssh server. 3389 is the port of the rdesktop server that waits for connections. The other is a port for our RDP client use to connect and view from.
Setting up the Windows client
Now that we have set up our Linux host we need to do the same for our Windows client. For Windows we start by enabling Remote Desktop. In Windows XP you go to Start–>All Programs–>Accessories–>Remote Desktop Connection. For the SSH tunnel we will use Plink. Simply download Plink.exe and drop the .exe file in a sub-folder, or somewhere it won’t be noticed. We will do the same with Netcat for our initial connection.
Making the connection
From the Windows client we will start by opening a temporary shell on port 1234.
C:\> nc -lvp 1234 -e cmd.exe
With the above syntax we should now have a Windows shell listening on port 1234. If your distro doesn’t come with Netcat pre-installed you can install it through your package manager. Whether yum, pacman, or apt-get the syntax should go like this:
# apt-get install netcat
We can now use Netcat on our Linux host to connect and get a shell. The -v parameter tells Netcat to be verbose. The IP address used here is the address of the Windows client. Finally, 1234 is the port we wish to connect to.
$ nc -v 192.168.1.12 1234
Now we should have a Windows command prompt for the remote client on our Linux machine. I chose 192.168.1.12 for the Windows machine’s IP address. Use whatever is appropriate for your network.
Once this is done we can run plink from the Windows shell on our Linux host.
C:\> plink -l username -pw password -R 3390:127.0.0.1:3389 192.168.1.11
What we’ve done here is tell plink the user name and password for the Linux host we are about to connect to. The -R parameter is used to tell ssh this is going to a remote host. The 3390 number we are connecting back to here is the port on our Linux machine. We can’t use 3389 as that port is already in use by xrdp. Obviously 127.0.0.1 is the loopback address on the Windows machine. 3389 is the port on the Windows machine we need to forward back to Linux. Finally, 192.168.1.11 is the IP address I’m using for our Linux host that we want to connect back to.
If everything went according to plan, we should see something like this from netstat.
$ netstat -antp Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 6294/sshd tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 6230/xrdp-sesman tcp 0 0 127.0.0.1:3390 0.0.0.0:* LISTEN 6227/xrdp
As you can tell we have the Windows machine connected on 127.0.0.1:3389. Simply running rdesktop on 127.0.0.1 should open Windows on our Linux machine.
$ rdesktop 127.0.0.1
Now you can close Netcat and use remote desktop over ssh encryption. I should note here that leaving an open shell like I’ve just done can pose a high security risk. If possible, you should start this from the Windows client with the same syntax to avoid opening a shell to the whole world.
Connecting with no DHCP
What we’ve done may not impress some of you. Connecting from one machine to another on the same subnet is not that hard. But we are now going to try and connect to another subnet. One which has Internet, but no DHCP. We’ll pretend the box at 10.0.0.10 has a web page on port 80. We’ll also pretend the Windows client on 192.168.1.12 has two network cards and thus two ip addresses to talk to both networks. Since we are not on that subnet and without dhcp we cannot simply view it by typing the ip address into our browser. SSH will allow us to tunnel through to this machine and send the service and web page running on port 80 back to our Linux host.
C:\> plink -l username -pw password -R 8080:10.0.0.10:80 192.168.1.11
Here we used almost the same syntax with plink as before. I decided I wanted the connection to start on port 8080 on my Linux host. This time we used the IP of the machine we wanted to connect to instead of 127.0.0.1. We chose to connect to it on port 80. Finally we sent this connection through the Windows client and back to the Linux host on 192.168.1.11. The service from 10.0.0.10 is now bound to a port 8080 on the localhost of our Linux box. Use http://127.0.0.1:8080 in the address bar of your browser to see the web page from 10.0.0.10.
Changing the scenario to Linux clients
I was surprised to find tunneling GUI administration over SSH was much simpler with Linux clients. No xrdp package was even needed. Only an ssh server was needed on the client we wish to monitor and an ssh client our box. From our command-line we start with like this:
$ ssh -X username@10.0.0.10
Here we are logging into the client’s ssh with -X to allow X11 forwarding. We will be prompted for the user’s password and taken to a secure shell. To create an interactive GUI session will be specific to your desktop. For KDE simply type the following:
$ startx -- :1
Users of the Gnome Desktop will have to use this command instead:
$ gnome-session
Any users who experience problems with this should look to configuring thier distro’s xinitrc and/or xsession files. The lines of these files can vary between distros and be stored in many different locations. However, I’ve found many distros, like Debian Sid, worked with no configuring or troubleshooting. Please see your distro’s documentation for help.
Once you have issued the command for your desktop session you should have a GUI desktop of the remote box. Unlike xrdp, this session will envelope your full monitor instead of a scalable window. You can switch between the remote session and your local desktop by toggling between Control+Alt+F7 and Control+Alt+F8. Just make sure to not shut down the session with the remote machine. Doing so may shutdown the client your are monitoring from and not make for very stealthy sleuthing.
Now that we are inside the remote machine we can use can use its SSH client or proxychains to tunnel deeper. Doing so will allow us to hop over networks with or without DHCP like before.
Conclusion
While this type of monitoring may seem intrusive, any serious administrator will find themselves needing to do this at some point. Whether you need to fix a remote machine with a GUI application, or making sure your employees aren’t saving lewd photos to a work machine. Using SSH not only protects you from attackers, it also allows tunnels to networks you can’t even ping, using this type of administration allows you to monitor without being easily noticed by the clients or interrupting their work. Please use this information responsibly and remember, “With great power comes great responsibility.”
