This article provides a brief insight of what is and what to use as Remote Desktop on Linux. I'm not trying to describe the concept itself because nowadays everyone should already be familiar with it. I would rather try to review the types of VNC servers out there, when and how we may use them.
In Linux you have many options but there are two that I like especially:
- the Virtual Network Computing (aka VNC) that basically sends your mouse and keyboard events to the remote machine and then capture and sends you back to you the remote system X11 frame buffer (the screen updates)
- the X11 forwarding over SSH which basically transforms the remote X-server into a X11 proxy server that allows you to run any program from the remote system by using the remote system resources. It forwards the window frame buffer over SSH so that the remote application looks like it runs locally on your system, since there is no remote desktop between. This is especial useful when you want to run an application that is installed on the other machine and to have its window on your local desktop in contrast with having it inside a remote desktop.
Virtual Network Computing
Depending on your Linux distribution your generic VNC server could be bundled in one package or another. For instance, the package that allows you to install/run the VNC server could be called as VNC-Server or TightVNC server or X11VNC. Or maybe something else. Depending on which package we are talking about the VNC server might hook directly on the X-server frame buffer and thus it might be capable of sharing with you the running X session frame buffer (i.e. you see what the others are doing on their desktop) or it might be just capable of starting a new (parallel) X session on a distinct display (not the display:0 of the existent X session, if any) so that the two (or maybe more) X11 sessions are isolated from each other, each of them running on a distinct display (the first X session runs on display 0, the next one on display 1, etc).
Why is this important? It's important because if you want to see what the other is doing on his desktop then you need a VNC server capable of hooking into and sharing the remote frame buffer. If you only want to work with your own remote desktop on the remote computer, within a parallel X session that the other remote operator cannot see (and conversely, you cannot see his/her desktop) then you will probably need a VNC server capable of starting a new remote X11-session and to share with you that X11 session frame buffer. If you only want to run an application installed on the remote system by using the remote system local resources (like memory, network, disk, etc) but to appear and to interfere onto your local desktop only (like it is installed and run locally) then you might just need X11 Forwarding over SSH.
This package allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.
For me this is just a real VNC because when I run it it hooks into the remote session frame buffer and then it shares that buffer over network on the local TCP port 5900 (or something). I connect to that remote host on port 5900 using any VNC aware client application (VNC-Viewer, Vinagre, you name it) and then I see (also can send mouse/keyboard events) what the remote operator sees on his/her desktop. Awesome!
For this we should be able to run this command on the remote machine:
x11vnc -display :0 & disown %1
Optionally you could also use the -ncache option that helps to cache screen content for rapid retrieval. Note that this mode consumes a huge amount of memory, both on the x11vnc server side and on the VNC viewer side. By using the symbol ampersand it causes the program to run in the background, so you'll get a new shell prompt instead of blocking until the program ends. disown on the other hand suppresses SIGHUP (hangup) signals so the program isn't automatically killed when the controlling terminal is closed. On short, if you run the command above like "x11vnc -display :0" then it will hungup when you will disconnect from the remote desktop, so that you need to start again this program if you want to be able to connect again the remote desktop viewer (see the next paragraphs). On the other hand, with the "& disown %1" you will suppress this behaviour and thus you can connect,disconnect,connect and so on.
When I run the above command I see a lot of info that scrolls before my eyes (you better read them!) and then, if everything is ok it says:
The VNC desktop is: my-system-name:0 PORT=5900
so now I know that if I connect to the "my-system-name" (whatever your remote system name is) to the port 5900 I will see everything that the remote operator sees on its desktop (desktop which is denoted by the number after the colon, where 0 is the first, 1 the second and so on).
You can also start that remote x11vnc thing without being logged at the remote console although you will somehow do that. You could use SSH to map a local port on your computer to point to other port in the remote system and whenever you connect to your local port a predefined command will magically run on the remote computer so that the x11vnc starts and waiting for you remote connection:
ssh -L 5900:localhost:5900 <remote-user>@<remote-host> 'x11vnc -localhost -display :0'
According to the SSH man what this -L [bind_address:]port:host:hostport does is: it specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine. I think this is fair enough, isn't it?
You could create a script that allows you either to create the SSH tunnel or to connect you VNC viewer to the running remote x11vnc server:
#!/bin/bash mode=$1 # open | view target=$2 # format: user@linux-box case $mode in 'open') if [ "$(echo $target | grep root)" ]; then ssh -L 5900:localhost:5900 $target 'x11vnc -localhost -display :0 -auth /var/lib/gdm/:0.Xauth' else ssh -L 5900:localhost:5900 $target 'x11vnc -localhost -display :0' fi ;; 'view'|'connect') #vncviewer -encodings "copyrect tight hextile" localhost:0 -compresslevel 7 -quality 5 -fullscreen vinagre localhost:5900 --fullscreen ;; *) echo -e "Usage: $0 <mode> <target>\n<mode> = open|view|connect\n<target> = user@linux-box" exit 1 esac
With this script I start a remote desktop session on any remote computer whenever I like it:
vnc-tunnel open my-remote-user@linux-box Password: ****** PORT=5900 The VNC desktop is: localhost:0
What I do later is to connect to the localhost (no port specified).
Let's try it, would we? (note that the screen capture below was taken from a connection that wasn't opened with the above script but with our x11vnc -display :0)
Depending on what VNC client application you might use (see a comparison here) you can connect to the remote system by using some options or others but basically you only have to provide the remote system name/ip and eventually the port number (where 5900 is just happening to be standard).
I would also like to add that if you want to see what the other is doing on his X11 desktop then the method described above is the only one that works like a charm, without additional hacking. It is lightweight and stable. Those additional methods brought in discussion (that basically work by defining a vnc library as X-server module so that the vnc is loaded by X-server at server startup) look more like a pain in the ass to me but if you want to give it a try then be my guest. Here and here is described this method in details.
I never used this server but my understanding is that it provides similar capabilities like the x11vnc above although it provides less features than x11vnc. You might give it a try, though.
Another server that I would recommend is this one: TightVNC. It allows you to create a full X11 session on the remote machine and to control it remotely. In contrast with the x11vnc discussed above this one does not allow you to share the running X11 remote session of the remote system (so that you cannot see the remote operator's desktop) but it is ok if you only want to run some application(s) that are installed (only) on the remote system or you just want to use the remote system resources.
It is easy to install, easy to configure and easy to use it.
Note that perhaps you have to configure a startup script on the remote system so that once you connect the remote VNC server it runs automatically that script which in turn will launch the X session for you. Such a script might look like this one (~/.vnc/xstartup which need also the execute file mode set):
#!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & #twm & xfce4-session
By default it comes with the xterm but who want to run the default X terminal anyway? Because it happens that I like the Xfce4 Desktop I instructed that xstartup script to launch xfce4-session instead of twm which is the old Tab Window Manager that no one wants it anymore. By assuming that you have installed the TightVNC server and you have also set up this small startup script you only need to start the vnc server daemon and that's it. You can connect the remote system.
This one is cool. You can actually forget about the remote desktop because you are going to launch the remote application which in turn will run on your local desktop. Yes, you heard well. They will sit on your desktop. What this means is that, if you have a multi-monitor setup you can place the remote application window wherever you like it. Now do that with the remote desktop where the remote graphic card is 1024 x 768 and besides that it supports only one monitor. You can't!
How I run this X11 forwarding? Simple. From your terminal try to open a remote SSH connection :
ssh user@linux-box -X
This -X will enable the X11 forwarding. In case you haven't set up the X11 forwarding authentication you will see something like this:
ssh user@linux-box -X Password: ****** Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.
You could also use the -Y option which enables trusted X11 forwarding which involves no security at all but that's ok if you run this one a trusted network (like your home).
So, basically this one is the main advantage if you would ask me but you don't, so you better read the article I mentioned below.
Now, if you think that this article was interesting don't forget to rate it. It shows me that you care and thus I will continue write about these things.