Accessing Remote Linux Server Graphical Applications from Your Desktop [Discussion]

Latest response

Wanted to start a discussion on partitially based on the tech brief

 

Accessing Remote Linux Server Graphical Applications from Your Desktop

 

The orgins of this document actually came from a need to create a minimal server enviroment. Though allow administrators to install and use 3rd party tools, such Oracle 11G. Which requiring the use of a GUI to do the installation.

 

Though after completing the task it was found that you didn't need to install a full desktop on your server. More so you didn't need to install a desktop at all.All that was need on the server was the package xauth. Though it was also found that you did need some supporting packages to make sure everything worked for all applications.

 

There are many different ways of achieveing this the desired outcome.

 

The key benefits of using X11 over SSH is:

  • Server can have less packages installed.
  • None of the desktop packages and services need to be installed (such as CUPS, Bluetooth, & Network Manager). Freeing CPU & Memory on the server.
  • User accesses server over a secure connection. Graphics are tunneled over SSH.

 

Though some of the disadvantages are:

  • Is not as fast over slow connections.
  • If user looses SSH connection. The graphical program is closed as well.

 

A key advantage of this technique over VNC is that VNC can be very CPU intensive on the server side. This can take away potential CPU time & memory from the target application(s) you are running on your server.

 

 

What are your thoughts?

 

Have you run into any issues?

 

Do you use a different approach to solve the same problem or findings?

Responses

If you're not separated from your Linux box by a firewall, you don't even need X-over-SSH. Then it simply becomes a question of which is of more concern: speed vs. security. If speed is your concern, add a port 6000 exception to your administration host's local firewall and just set your DISPLAY variable to point to your local Xserver's display.

 

At any rate, in our environment, we use Cygwin/X for our Windows 2008-based administration servers, then either do tunneled X or direct X, depending on criticality of speed and overall network conditions. Even before this job, that was the way I administered most UNIX systems remotely (I've used Exceed, NetSarang and Reflections prior to switching to Cygwin). Only real downside of Cygwin's Xserver implementation is that, around five years ago, they updated one of the libs and cut-and-paste no longer work (you can cut from but not paste to a Cygwin-hosted X-client).

@Thomas Jones

 

You bring up a good point. Actually that was exactly how I also had used X11 forwarding for years. Though there are some disadvantages given tunneling through SSH is now an option:

 

  •  Communication with the server is not secure.
  •  Firwall port on the client side has to be open to allow for the traffic to reach the X11 server running on your client.

           - With X11 forwarding over SSH you don't have to do this.

 

  •  Firwall port on server side  has  to be open to allow for X11 traffic to work.

           - This is not needed if you forward over SSH. The only port that has to be open is SSH.

 

  •  You have to Set the DISPLAY variable correctly on the server side.

          -  No need to set DISPLAY variable on the server side. With X11 forwarding through SSH it's done for you.

          -  Usually is a lot of fun & pain trying to get correct a lot of the time.

 

  •  You have to mess with xhost command to allow for the server to communicate with the client

           - With X11 forwarding over SSH you don't even need the xhost command installed on the system. It is not needed.

 

Also most on local networks don't have an issue with network speeds.. But the way you guys use your admin server is a great way to get around that issue with speeds when you are over the internet. Having a local machine on the network then using RDP to get to that, is also  a great way to avoid applications closing when you get disconnected. 

 

The Xservers you mention are great options. Xming was pointed for Windows users out since it was an easier to configure & free. It also is a project that is still being worked on. Though all the X servers you point out will work as well  in the same way with Putty.

The X tunneled via SSH is a great option. However, you can find interesting these alternatives:

 

A VNC session tunneled with ssh (and compressed) can do the trick (The "vinagre" client will create the ssh tunnel for you). Plus, it can be recovered if the connection is lost.

 

A similar enhanced option is using NX for which you have three options:

* NoMachine - the "original" one. It's gratis, but not completely free.

* FreeNX - the first free NX implementation

* NeatX - another free NX implementation done by google employee(s)

 

What a pity there is no standalone spice server that can be installed in physical machines.

 

My 2 cents,

 

M*

Exactly: naked vs. tunneled is a question of speed vs. security. On a sufficiently resource-constrained system (either the host you're trying to talk to or your administration host), the periodic renegotiation of the session-encryption does cause overhead. This is especially true if using more complex encryption algorithms or configuring to use longer key-lengths.

 

When it comes to the rest, it depends what you're using for a client. Some clients can be configured to do the redirection setup automatically. Even if your client doesn't/can't it's trivial to set it up in your your shell init script (e.g., pumping `who am i` output through `sed`).

 

Primary value of Cygwin being that it provides a local UNIX-y toolset above and beyond simply providing an X-server (sometimes, it's really helpful to have the openssl s_client utility available on a system other than the one that's having SSL issues). With Cygwin installed, it's easy to ignore that you're stuck using a Windows-based system as your administration host. ;)

The various VNC-based solutions suffer from the same problems that X-RDP does: they aren't core utilities. In security-conscious environments, there's a higher likelihood of finding  basic X-components present than any of the add-on utilities: VNC (and similar) utilities are frequently forbidden because they're not even part of the core OS components.

 

This is a problem I've run into at banks, healthcare, government and military customers. All tend to be on the paranoid end of the security spectrum and yank out whole swaths of a Linux or other UNIX build. Frequently, the only things left behind are a subset of the core OS packages.

 

For the record, I used to love the VNC option (especially TightVNC). But it was always harder to get it past security folks than it was to get a client-only tool that enabled X-redirection.

I have a dedicated machine running an X desktop in my datacenter. I connect to that with VNC-through-SSH, and from there I SSH on to my servers from where I tunnel X programs back to the desktop.

It may sound a bit silly and in most situations it would be, but in my case it's the simplest option. X is too fragile and slow over the distance from my office to the datacenter, and VNC would require having X on servers which security folks turn red about.

 

There are other solutions out there but this works best for me.

I have a dedicated jump server running Fedora 16 bound to Active Directory with xRDP enabled.  Users can login to that jump server using Remote Desktop with their Active Directory credentials from Windows, Mac and Linux clients and use that jump server to connect to our RHEL servers via ssh -X. Since the Jump Server and all RHEL servers are Virtual Machines, the performance is almost native speed.   This allows our users to VPN into our environment, connect to a jump server giving them a modern desktop and have X access to all of our servers.  Doing so allows us to keep our RHEL servers as lean as possible (no, desktop, VNC, etc.).   Plus, with xRDP using Active Directory credentials, users connecting to the jumpserver get Kerberos tickets and can ssh to our RHEL servers (also bound to AD) using Kerberos versus passwords.