Remote Desktop on Linux, Managing GUI Displays Remotely
In this guide I’ll explain how to manage X displays (GUI) on Linux servers, desktops in best possible way and remotely. I’m still a CLI guy, barely use the GUI but nowadays more and more GUI tools added to many Linux flavors so it’s unavoidable to use them every now and then. This guide is based on SUSE Linux Enterprise Desktop 10 (SLED) and the default display manager Gnome but should be very similar to OpenSUSE or other releases.
GUI in general
On UNIX the graphical display is managed in the same fashion as many other common services with client-server components. Your system starts an X server in the background at the boot process when you reach runlevel 5, it is supposed to be the default on most distributions. When you run a GUI application you actually display that through your local X server, that’s the default behavior unless you tell your system where you want to display your GUI application.
It’s very important especially in a server environment. Nowadays we rarely sit in front of the server or desktop we are about to manage, we do these remotely, remote control utilities have come a long way. Using these in a Linux environment is the focus of this guide.
It’s actually pretty unnecessary for most servers to run GUI desktop, it’s just a wasting your resources, opening unnecessary ports, weakening security, risking system stability due to running something you don’t actually need. Hence I usually configure my servers to start up in runlevel 3 which is the multi user environment without GUI, it’s like turning GUI off but have everything else.
We can run all installed GUI application and display them anywhere in our network on any desktop, server where an appropriately configured X server is available. It’s no issue on Linux, they all come with it unless you unselected it during installation.
You should try these in your test environment unless you are sure that you would have no issues on your production systems! These could cause major security threats, only enable these on trusted, firewall protected private networks. Do not forget to turn off AppArmor and SuSEFirewall services neither.
Getting the remote server ready
Create an ssh session then switch the remote server back to runlevel 3 if it’s not already:
desktop:~ > ssh root@server Password: server:~ # init 3 server:~ # runlevel 5 3 server:~ # logout desktop:~ >
No GUI desktop or X server should be running anymore.
ssh tunneling whereas possible
It’s the easiest and the most secure, many distributions are set to enable this so let’s check it out:
desktop:~ > su - Password: desktop:~ # grep X11Forwarding /etc/ssh/sshd_config X11Forwarding yes
That’s all we need! Now open up a terminal on your Linux GUI desktop, log into your remote server with an indication of using X11 forwarding:
desktop:~ > ssh -X root@server Password: server:~ # xclock
The result of this should be an appearing GUI clock on your Linux desktop. If you want to get the prompt back and start the GUI as well put & at the end of the command like:
server:~ # xclock &
Some systems are customized heavily, it depends on the global ssh client and server configurations but if you didn’t manage to get the GUI clock on your desktop try this:
desktop:~ > ssh -Y root@server Password: server:~ # xclock
The opportunities of this method are endless. You just run the commands over ssh, you don’t actually need to log in:
desktop:~ > ssh -Y root@server 'xclock' Password:
Same affect. If you configured ssh keys you may not need to put your password in at all. The only issue with this is the efficiency, it can’t handle big stuff because ssh application is limited in flow control buffers. Opening up big images with GUI viewer this way or other GUI intensive applications will probably perform pretty slow.
With this method you could run all your YaST2 management tools executed from the command line on the remote server and displayed on the local Linux desktop. For example:
desktop:~ > ssh -X root@server Password: server:~ # yast2 -l Available modules: GenProf LogProf SD_AddProfile SD_DeleteProfile SD_EditProfile SD_Report -snip-
Or the entire YaST interface:
desktop:~ > ssh -X root@server Password: server:~ # yast2
The following is another method, more efficient, more flexible with many other features but less secure. My Linux desktop runs in runlevel 5, I’m already logged in, have my GUI desktop ready. I need to make few changes to my local X server to be able to receive GUI connections from remote systems.
Open up a terminal on your desktop then:
desktop:~ > runlevel N 5 desktop:~ > ps ax | grep X 22616 tty7 Ss+ 0:01 /usr/X11R6/bin/X :0 -audit 0 -br -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 23412 pts/0 S+ 0:00 grep X
The server is running but it has an option turned on for not to listen to remote connections. It’s the default security model in all Linux desktops lately so we have to get rid of the -nolisten tcp string.
desktop:~ > su - desktop:~ # vi /etc/sysconfig/displaymanager -snip- DISPLAYMANAGER_REMOTE_ACCESS="yes" DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes" -snip desktop:~ # SuSEconfig --module xdm Starting SuSEconfig, the SuSE Configuration Tool... Running module xdm only Reading /etc/sysconfig and updating the system... Executing /sbin/conf.d/SuSEconfig.xdm... Installing new /etc/X11/xdm/Xservers Installing new /etc/X11/xdm/xdm-config Finished. desktop:~ # SuSEconfig --module gdm Starting SuSEconfig, the SuSE Configuration Tool... Running module gdm only Reading /etc/sysconfig and updating the system... Executing /sbin/conf.d/SuSEconfig.gdm... Finished.
To see the affect we need to restart the X server, the entire GUI desktop. SAVE all your documents, etc. on the desktop then hit CTRL+ALT+BACKPSPACE. Once you got the login screen back, log in and check the parameters…
desktop:~ > ps ax | grep X 24140 tty7 Ss+ 0:01 /usr/X11R6/bin/X :0 -audit 0 -br -auth /var/lib/gdm/:0.Xauth vt7 24175 pts/0 S+ 0:00 grep X desktop:~ >
We are actually using the default Gnome display manager (gdm) only but running the xdm module can’t hurt. As shown the blocking option is gone.
It’s the SuSE way of doing this. What is good about this is that it updates all the necessary files around X, you don’t need to worry about anything else after this. If you wanted though to look at other ways for example the Gnome designed way:
desktop:~ > su - Password: desktop:~ # gdmsetup
What we did here is selecting “Enable XDMCP” option and unselecting the “Deny TCP…” option right at the bottom but don’t do anything here, it’s done already, it is just for reference.
Now we need to tell our X server where we accept remote connections from. You can do this by host basis:
desktop:~ > xhost +server.domain.co.nz desktop:~ >
To turn it back on again just replace + with – and remember that it’s for the current session only. (reboot, logout clears these settings)
It may be too paranoid on trusted networks though so let’s just disable access control:
desktop:~ > xhost + desktop:~ >
To display a remote GUI on a local desktop we need to log into our server again without those ssh switches shown earlier then tell the remote session where our display is located.
desktop:~ > ssh root@server Password: server:~ # export DISPLAY=desktop.domain.co.nz:0 server:~ # xclock
The :0 tells the environment which display to export the GUI to. In default most systems have one, starts from number 0. It produces the same affect, clock appearing on the Linux desktop but in a bit more complicated way. If you don’t run big GUI applications then the ssh tunneled option is probably the best for you but this method has some other advantages.
Remote desktop to an existing Gnome session
It’s like VNC to an already running GUI desktop, in fact it is. It’s built into the Gnome environment and after the settings shown above you can enable this feature easily:
desktop:~ > su - Password: desktop:~ # vino-preferences
You can allow just viewing or enable controlling too with various options like confirmation and password. Once you set these, a small application will be running on your desktop called vino-server listening to connections. You can connect to it then by any VNC compatible client like TightVNC, etc. from either Linux or Windows:
desktop2:~ > vncviewer desktop.domain.co.nz:0
Alternatively you could click on the GUI icon amongst your application. Remember in Linux environment, it’s always useful to specify the display right after the host name, you could have many! In the default SLED 10 installation you get TightVNC which does decent compression and performance on Linux.
Terminal server, multiple remote desktop connections
You could have as many virtual desktops you like to a certain server with individual user sessions. Since we enabled XDMCP protocol earlier we can create multiple remote desktop sessions to a single host. It may not be useful for a desktop system but might be for an application server. Ensure that the X server is running on the remote system, listens to remote tcp connections and running in runlevel 5 as shown earlier. Remember gdmsetup is the command you need to set up the welcome screen but it should all be done by defaults.
Let’s see how to connect to an application server and create a virtual desktop over XDMCP:
desktop:~ > X :1 -query server.domain.co.nz
:1 tells the server we want this connection to the second display of ours, usually on terminal 9 (F9 key). It will start a brand new X display for you off the remote server on your local desktop. To switch back to the primary desktop hit CTR+ALT+F7. You can start few more displays with no problems this way, you could switch between them by CTR+ALT+F[terminalnumber].(usually above 7 and in order)
Once finished hit CTRL+ALT+BACKPSPACE to close the session, you will be dropped back to the initiating shell session on the primary desktop on terminal 7.
OFF: X server for Windows
There is a very good open source one available, if you have Windows desktop, install this:
The configuration should be straight forward and out of the scope of this guide.