Source: https://www.redwireservices.com/remote-x11-for-linux-unix

The Problem

One of my most feared questions from end users is “how can I interact with an X11 GUI application on our remote Linux system if I have no access to the physical console, X11 isn’t installed, and there is no VNC access?”  After hearing this many times at one site, I wrote a script to automate the server side process, but even that does not address the whole story.  I’m writing this post as a quick reference when I field this question in the future, and I hope it helps you, too.

The problem is that most system administrators do not install X11, Xorg, or other GUI interfaces on Linux and Unix systems as this introduces more packages to manage and patch, more security bugs to fix/mitigate, and a larger install footprint (more used space). That last point may seem moot today, but with many environments deploying hundreds of virtual machines, 200-400MB of extra space per VM can really add up quickly (see my latest presentation on Open Source Data Deduplication for more ideas on saving space in these environments).  If you consider the overhead of installing a modern desktop/windowing system such as Gnome or KDE, it could easily more than double the data size footprint of a Linux server.

OK, many environments don’t install the Linux/Unix GUI bits (also known as X11 or Xorg server), so who cares, I can just install everything via the command line, right?  Well, yes, for the most part you can just install applications via the command line and forget this whole issue.  However, there are a few vendor applications, notably including Oracle Database and Application Server products, that are difficult if not impossible to install without a GUI.

The Solution

The modern solution to the problem stated above is to tunnel X11 traffic over ssh (securely), and display it on your workstation, whether it be Windows, Mac OS X, or Linux.  For sake of helping the most folks, we’ll focus on Windows workstations here, but Linux and Mac OS X should work with only the server side changes we write here (just connect with the command line ssh -Y your_username@your_servername.com).

In certain circumstances, it may be advantageous to setup a VNC server to accomplish the same thing, but that requires more of X11 and an windowing environment be configured on the server side, and we’d like to avoid as many server side changes as possible, as many users won’t have access to make these changes themselves.

PROCESS OVERVIEW

In order to obtain the ability to interact with an X11 GUI remotely, we will follow these general steps:

  1. Ensure that the foundational X11 packages are installed
  2. Ensure that OpenSSH server is configured to forward X11 connections
  3. Configure a local X11 server on our workstation
  4. Configure our ssh application to forward X11 requests
  5. Test with a simple application
  6. Configured authentication if user changes are needed
  7. Move on with the task at hand
 

1) ENSURE THAT THE FOUNDATIONAL X11 PACKAGES ARE INSTALLED

In order to use remote X11, you must have a few X11 packages installed on the server.  In many cases these are already installed, but you may have to ask your System Administrator to install them for you, it’s easy:

RHEL/CentOS/Fedora (xterm is optional, but beneficial for testing):

sudo yum install xorg-x11-xauth xterm
sudo yum install libXext.x86_64
sudo yum install libXrender.x86_64
sudo yum install libXtst.x86_64

2) ENSURE THAT OPENSSH SERVER IS CONFIGURED TO FORWARD X11 CONNECTIONS

On RHEL and related RedHat based servers, the file to check is /etc/ssh/sshd_config.  Review this file for the following line:

X11Forwarding yes

If that line is preceded by a comment (#) or is set to no, update the file to match the above, and restart your ssh server daemon (be careful here — if you made an error you may lock yourself out of the server).

sudo /etc/init.d/sshd restart

3) CONFIGURE A LOCAL X11 SERVER ON YOUR WORKSTATION

Next we need to install and configure a local X11 server, Xming or Cygwin/X are popular

Click Xming to start the Xming X11 Server on your Desktop/Workstation

free choices for Windows.  Simply download and follow the install instructions for these packages, Xming is by far easier to setup for beginners.  After the install is complete, and you’ve rebooted your workstation/desktop (if requested), start the X11 server application from the start menu.

4) CONFIGURE OUR SSH APPLICATION TO FORWARD X11 REQUESTS

Next, we need to ensure that our ssh client is configured to forward X11 requests from the server.  If you are using Cygwin/X, a Mac, or a Linux desktop, simple open up a terminal and preface your ssh command with -Y, for example:

ssh -Y your_username@your_server.your_domain.com

That will tell SSH to forward all X11 requests to your local desktop.  For Windows, the most popular client is PuTTY.  To achieve the same result in PuTTY, load the profile of the server you wish to connect to, or simply fill out the connection details.  Next expand the Connection and SSH options on the left hand side.  Under SSH and then X11, ensure that Enable X11 Forwarding is checked.

PuTTY Configuration Window Show X11 Forwarding Enabled.

Finally, click the Open button to connect to the remote server.

5) TEST WITH A SIMPLE APPLICATION

If everything has gone according to plan you now have a server configured to allow X11 connections, an ssh client configured likewise, and you are ready to test.  When connecting to the remote server (last step in part 4 above), you may see a message like this:

/usr/bin/xauth:  creating new authority file /home/ec2-user/.Xauthority

This is a normal message, and in fact it tells us that part of our changes are working!  This file contains an authentication token required to connect with the X11 server.  Now to test, it’s easy, just enter this command on the remote ssh session:

xterm

Wait just a few seconds depending on your internet/network connection speed, and you should see the following.

Xterm shown via remote X11 on Windows

xterm displayed on Windows from a remote Linux Server

If you see something similar, congratulations!  Remote X11 connections are working!

6) CONFIGURED AUTHENTICATION IF USER CHANGES ARE NEEDED

X11 forwarding is working, great!  These days, however, users are often not allowed to log in as root, which is great for security, but adds yet another step to our process.  In step 5 we ran xterm as ourselves, which validates our setup is proper.  Try running the same command as another user, though, via sudo and you’ll likely see an error like the following.

X11 Error from Improper .Xauthority

X11 Error from Improper Xauth Configuration

The problem here is that a .Xauthority file is created automatically at log in time for our user, allowing our user access to our local X11 server (on our desktop).  However, when root tries to access this connection it is denied without the proper permissions.

To work around this, simply copy the .Xauthority file from your user directory to the user you want to work with (root for example).  Note that this should be done from your user account, not as root:

sudo cp ~/.Xauthority ~root/
sudo /bin/chown root ~root/.Xauthority

Try running xterm again as root, it should work.

sudo xterm

7) MOVE ON WITH THE TASK AT HAND

There you have it, now that you can login remotely and still access a GUI as any user, you can move on to installing your GUI centric application such as Oracle.

sudo cp ~/.Xauthority ~oracle/
sudo /bin/chown oracle ~oracle/.Xauthority
sudo su - oracle
./runInstaller

Enjoy!

Gotchas

When installing or configuring an application, like those from Oracle, keep in mind that a break in your internet connection or other problems with your link may cause the remote program to be closed!  So while it may be tempting to let an X11 process run overnight, you may have better results sticking around until the process completes.  If your installer/application stops to ask you a question and your link does fail, you will likely lose all the work completed to that point and have to start all over again.  Save early, save often, as they say.

Conclusion

If this was helpful, please drop us a line at info at redwireservices.com, @RedWireServices on Twitter, or using the contact page.  If you have additional tips to add, please add a comment below and I will update the post accordingly to help as many as possible.

Finally, if you or your company are in need of IT disaster recovery planning, backup system assistance, storage, or archival help, give us a ring at (206) 829-8621.