SUSE Conversations

Remote Desktop on Linux, Managing GUI Displays Remotely


By: variia

January 23, 2009 4:35 pm




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
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 -
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
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
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'

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
server:~ # yast2 -l
Available modules:


Or the entire YaST interface:

desktop:~ > ssh -X root@server
server:~ # yast2

XDMCP protocol


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
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
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...

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 -
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
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
server:~ # export
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 -
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

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

: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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Tags: ,
Categories: SUSE Linux Enterprise Desktop, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.


  1. By:cyberorg

    RDP is Remote Desktop Protocol:

  2. By:ecyoung

    At first I thought maybe Novell had worked something out with Microsoft (as part of the MS-Novell agreement) to get RDP implemented as a host protocol on Suse, but then I realized this article seems to be misnamed.

  3. By:variia

    Thanks for your comment and the link, both useful. This solution is based on packages that are natively available and supported on both Gnome and SLEx10, requires no extra software to install not to mention that this method could be used on any Linux flavor and working for years.


  4. By:variia

    Thanks for your comment. I’m well aware of what RDP is and yes I agree, the topic name may not be the best hence changed it. Not everybody is that familiar with these technologies, RDP is know by many nowadays. This was intended for newbies or for audience with not much Linux experience around remote desktop technologies and I thought RDP is easier to relate… sorry for the confusion.


  5. By:cyberorg

    Nomad uses RDP for remote desktop natively on openSUSE 11.1 and SLE 11.

    Cheers :)

  6. By:upengan78

    This Article is very useful. I was searching for ‘remote_desktop pattern opensuse ‘ and came across this one. After reading this document I learned how I can connect to display :0 on a linux machine using Vino-preferences. It works nicely.

    Thanks! God bless!