Jump to content
xisto Community
Sign in to follow this  
dserban

Linux – Secure Vnc Over An Ssh Tunnel With Port Forwarding

Recommended Posts

VNC stands for Virtual Network computing.

It's a technology that has been around for a long time.

 

It was originally designed by some people at AT&T Labs a long time ago.

 

It is basically a cross-platform way for you to connect from one computer over to another computer and to be able to see a desktop that is being "served up" by the remote machine and run any graphical application – so it’s graphics-based as opposed to SSH which is text-based. In other words you can run a little application and using this application connect to another computer on your local network or over the Internet. Similar technologies have been developed by Microsoft (Remote Desktop Connection).

 

VNC is very well supported on multiple platforms, there are lots of packages for VNC, you can find VNC for Linux, Windows, Mac. You can connect from a Linux machine to a Windows box, or from Windows to Mac, Mac to Windows – it makes no difference what operating system you’re running it on, the underlying communication protocol is the same and it's based on the same set of specifications across the operating system spectrum.

 

Basically what you do is you run a little VNC server on the machine that you want to connect to, and then on the one you’re connecting from you are going to run a little viewer – this is the name for the VNC client application, it’s a very small widget that just lets you view the desktop of the remote machine.

 

A couple of issues with VNC:

The biggest issue is that it’s completely insecure. When you first run the server it asks you for a password that it will use to prompt clients / viewers that try to connect to it, but the whole thing is in plain text and historically it has been very insecure.

It can also be a little slow at times, especially when transferring very graphics-rich desktop environments, but it’s really not that bad, because it’s oviously trying to compress the graphics over the connection. But lagging is occasionally an issue.

 

There are several different ways to set up VNC on Linux.

You can get different VNC packages (RealVNC - which is the original VNC software, TightVNC – which is very common, UltraVNC … on the Mac there is something called "Chicken of the VNC", also OSXvnc).

TightVNC is nice because it runs on both Windows and Linux (it doesn’t run on the Mac as far as I know).

 

But it doesn't really matter, you don't necessarily have to have server and client software belonging to the same package. In other words, you could be running a TightVNC server on your Linux machine and using a VNC viewer that belongs to "Chicken of the VNC" on a Mac to connect to the Linux machine.

 

The first thing you need to do is install TightVNC on both machines. For my example I am going to connect between two Linux machines, but it really should make no difference.

Let's say you have a Linux machine at home in the basement, and let's call that "server", and you have a Linux laptop called "laptop".

On the server machine, you are going to need to run the VNC server application. I am going to first give you an example of how to connect without encryption, just totally insecure, just to kind of explain how to do it, and then we'll complicate things a little bit.

Let's say your server's IP address on your local network is 192.168.1.50, and let's say your laptop is 192.168.1.60.

On the server / target desktop, where you are going to try to connect to, all you need to do is to run:

CONSOLE
vncserver :1

You don't need to do this as root – you just do this as your normal user, that will work without problems.

It will ask you for a password, which is not going to add too much to the security of the communication, but it's just a way to authenticate on a very weak level.

You'll see some startup messages, you will see something about how it's creating a hidden directory in your home directory called .vnc, and it's creating a little script in there called xstartup.

This $HOME/.vnc/xstartup script is kind of the equivalent of .xinitrc (the hidden script that has a list of stuff that will run before X is started when you do startx). This is where you are going to specify what window manager you want to run when you're running the VNC server. It defaults to TWM.

You can have multiple desktops, meaning multiple servers running at the same time, and these will need to use different listener ports – 5900 and up, so :1 means it's going to be listening on port 5901, but I will explain this in more detail further down below.

Before we do anything on the client side, let's stop the server:

CONSOLE
vncserver –kill :1

Now, let's go into that hidden .vnc directory on the server and edit the xstartup file. At the very bottom you should see what window manager is set to run by default. Like I said, you might see an entry for TWM. You want to comment this line by putting a hash mark at the beginning:

CONSOLE
#twm&

and add a new line right below it, and pick a window manager. Let's say you have FluxBox – I would pick something lightweight, so maybe install FluxBox if you don't already have it ( http://fluxbox.org/ ) and then put on the line underneath it:

CONSOLE
exec fluxbox

FluxBox doesn't need the ampersand if you use the exec command, it will just run it in the background.

Save that file, then go back out and now run the server again:

CONSOLE
vncserver :1

Now, like I said, your server machine is 192.168.1.50.

Now go over to your laptop and assuming you have VNC installed on it, open up a terminal and type:

CONSOLE
vncviewer 192.168.1.50:1

The VNC viewer is, again, the client end piece of software that you use to connect to the VNC server 192.168.1.50 on port 5901.

The next thing you see after typing in the password is the default FluxBox installation. You can now mouse into the window and right-click and get the Fluxbox menu and you can run applications etc.

If you were now to go back over and look at the screen on your server in the basement, you would see that nothing has changed – the VNC viewer is not controlling the desktop that you normally run. It's kind of running a new desktop in the background and you can't see that desktop on the server's monitor itself.

Again, I highly recommend using a lightweight window manager with VNC.

 

Now, like I said, what we've done so far has been completely insecure – the communication wasn't encrypted, the password could have very easily been sniffed.

 

But the better way of running it is over SSH - and this is what I always do - and this is also the way that most of the docs I have seen recommend.

 

Basically, what you are going to be doing is you are going to be using SSH tunneling. I didn't go into too much detail about tunneling in the other article ( http://forums.xisto.com/topic/93867-topic/?findpost=1064375719 ), but tunneling is basically a way to connect two computers over SSH on different ports. It would be a good idea at this point to go back to that article and refresh your memory. The reason why SSH tunneling is important is that you are going to be forwarding the port on the VNC server machine (5901) to a local (different) port on your laptop, and connecting your client-side VNC viewer to that local (different) port, which allows you to display the FluxBox desktop securely, over an encrypted SSH connection.

 

So the way you want to do this is to still run the server the same way:

CONSOLE
vncserver :1

- there is no change there.

And then on the laptop you're going to start a VNC tunnel – this is what you need to do:

Normally the syntax for SSH is very simple:

CONSOLE
ssh 192.168.1.50

to connect to the server from the laptop.

We are going to change that to include the "-L" switch in the middle. "-L" stands for local port forwarding:

CONSOLE
ssh –L 5902:192.168.1.50:5901 192.168.1.50 cat - &

You have thus effectively forwarded the laptop's (local) 5902 port to the server's (remote) 5901 port, so you are creating a tunnel from the server's 5901 port to the laptop's 5902 port.

We needed to specify the full port 5901 here because ssh is not aware of VNC's port naming convention whereby ":1" actually stands for port 5901.

The "cat -" command at the end is only there for the purpose of keeping the connection open. You could use any other command that does not finish. It could be left blank, too, thereby opening a shell, but then you would need a controlling interactive terminal and therefore you could not be using the ssh command in a script.

 

Now that you've done that, instead of pointing the VNC viewer to the server's IP address with display :1, which is mapped to port 5901, we are going to point it to the laptop's own loopback IP address with display :2, which is mapped to port 5902.

That is the whole point of the tunnel.

So in another terminal on the laptop you are going to run:

CONSOLE
vncviewer 127.0.0.1:2

and that will connect your VNC viewer to your laptop's local 5902 port, which is forwarded over an encrypted SSH tunnel to the server's 5901 port, where you have your VNC server running.

 

There is a little twist here, though – VNC by default doesn't let you connect to your actual desktop – it's running this other FluxBox desktop in the background (or whatever window manager you choose to configure in that xstartup script in .vnc).But let's say you want to connect to your actual desktop on the server machine. In this case we need to be using a different piece of server software for that - x11vnc: the VNC server for real X displays – this one is a little buggy though, don't expect a completely perfect experience. But it works if you don't get too fancy with it. I encourage you to try it out.

Use your package manager and search for x11vnc and go ahead and install it.

What x11vnc does is it basically runs a single VNC server connection on :0 (that's the digit zero, not the capital letter O), which, remember, maps into port 5900. That's because you are only logged into one desktop at any given time, so if you're logged into the main desktop session, that is going to be port 5900.

On the server machine, just run the command:

CONSOLE
x11vnc

- that's all you need to do.

Then you go to your laptop and it's very similar to what we did so far. We are going to forward the laptop's local 5900 port to the server's 5900 port. You would just type:

CONSOLE
ssh –L 5900:192.168.1.50:5900 192.168.1.50 cat - &

And then in another terminal on the laptop you are going to run:

CONSOLE
vncviewer 127.0.0.1:0

- and you'll see the desktop that you're running on your server.

 

There is stuff that you can play around with, like the level of compression and various other settings.

 

If you want to do this over the Internet there is not much that needs to be changed, except for the fact that you obviously have to take care of your NAT router and your firewall. In other words, you have to establish port forwarding rules for port 5900 or 5901 (as the case may be) to be forwarded to your server machine. And do not confuse this type of port forwarding (which is of the router / firewall variety) with what I have described above (which is port forwarding of the SSH tunnel variety).

Let's say the Internet-facing IP address of your router is 209.1.1.1 – you would just type:

CONSOLE
ssh –L 5902:209.1.1.1:5901 209.1.1.1 cat - &

CONSOLE
ssh –L 5900:209.1.1.1:5900 209.1.1.1 cat - &

respectively, because you have firewall-forwarded both the SSH and the VNC ports.

 

So definitely go ahead and play around with VNC, you'll really like it and when you combine VNC with SSH you've got a really nice, really killer combination of encryption plus being able to connect graphically to another desktop.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.