JDPFu.com 2024

Background

X/Windows, or simply “X”, is the graphical display system used by almost every UNIX and Linux system. It is a client/server protocol, but the client runs in the client application and the server runs on the display device – usually your local desktop. X works locally and remotely in the same manner with the control of where a GUI should be displayed controlled by the “DISPLAY” environment variable. X is the lowest level library that everything else graphical on a Linux system uses to put graphics on the screen and to get input from a keyboard and mouse. X was created in the early 1980s and has been around for 30+ years. The X-Consortium was created to standardize the protocol. Sun, IBM, HP, Dec, and Microsoft were members. Yes, Microsoft. Check out the wikipedia article on X/Windows for more. MIT has been at the center of X/Windows development all this time. I believe the FLOSS “MIT license” was created to support the release of X source code to everyone, including the companies involved. For many, many years (maybe 20?), the code for X/Windows was known to leak memory – meaning that your X programs would eventually crash as system memory was exhausted. These days, that isn’t much of an issue and hasn’t been for about 10 years.

Ubuntu, Redhat, SuSE, Debian, Gentoo, Slackware, and pretty much every other Linux distro with a GUI runs X. They can all provide remote access and connect to remote systems. You don’t need to do very much to access these capabilities.

X/Windows is really X-Clients and X-Servers

In the old days, you might have an X-Station on your desk with just enough CPU, RAM, storage and networking to connect to an “X-client” running on a server in another building. Back then, workstations were expensive – $10k – so having graphical terminals for $1k each was a great idea. The X-Station device has an “X-Server” program running running on it. These days, any computer you can buy will have enough resources to run X. Heck, my portable Nokia N800 runs X and probably has more computing power than an X-Station. It definitely has much more RAM. If you have a GUI running on a Linux system, you are 99% likely to have an X-Server running. It can accept requests from X-clients running locally or from X-clients running from machines all over the world. Sounds impressive AND this has been around for 30+ years? Yep.

DISPLAY Environment Variable

To tell X-clients (applications) where to send the display, where to get keyboard and mouse inputs, we set the DISPLAY environment variable. The form is:

export DISPLAY={machine}:{X-instance}.{screen}

That looks complex. Here are a few examples for clarity.

The X-server will accept connections from the local machine, X-server instance ‘0’ on the first screen. X was written by C programmers and we all know that you start counting from “0” in the C language, right?

export DISPLAY=:0.0

If you have 2 monitors and they work, normally, you can use

export DISPLAY=:0.1

xterm -sb

A remote connection example where you remote into another machine, but want the GUI and all input displayed back on your current desktop. In the old days, you would telnet to the remote machine, set your DISPLAY like this:

export DISPLAY=romulus:0.0

X/Windows Weenie Security

That wouldn’t work? Why not? X has a really weenie security model – these days it wouldn’t be considered security at all. The X-Server process must be told to accept client connections from machines that are not the localhost. That is accomplished by the xhost command on the X-server.

xhost +machine

xhost +romulus

xhost +romulus +regulus + deneb +icarus

I remember hating to remember to set these permissions since they were lost with every logout on the X-server.

xhost +

Basically, I’d open a new terminal, usually an xterm, then telnet to the remote machine, set my DISPLAY, the run the program. When memory was tight, specific machines would have specific programs loaded – so everyone in the lab would remote into a specific SPARC and run Mozilla to surf the internet. Since UNIX systems had shared libraries, the program would have just 1 copy in memory – anyway, it was more efficient if we all ran the same programs on the same machine.

ssh tunneling X/Windows

I love ssh and use it for all remote connections, even those on my local LAN. ssh has X/Windows tunneling built in. By using this tunnel the DISPLAY is automatically set for you AND you don’t need to run xhost +{remote machine}. Sounds too good to be true – there must be a very complex setup needed. Nope. We just need to remember to add -X to our ssh command. That’s it.

ssh -X userid@remote_machine

will create an X/Windows tunnel and any GUI applications will be sent down that tunnel and displayed locally. Well, sorta – there is a catch. The ssh server on the remote machine must allow X-Tunnels. This is set in the sshd_config file. Mine is located in /etc/ssh/sshd_config
The setting is

X11Forwarding yes

Most of the time, I actually run the remote application in the ssh -X command too.

ssh -X userid@remote_machine "ooffice spreadsheet.xls"

This is really powerful. If you’ve ever heard of seamless remote applications then you understand. Every X application can be sent from a remote machine. They will be displayed on the local machine just like any other window is. On a LAN, you probably won’t notice any lag either.

So far, we’ve learned how to setup a secure, encrypted connection, how to set our DISPLAY (or let ssh do it automatically) and have a remote application get displayed on our local machine. Nice, huh?

Read a professional article about x-forwarding.

Remote Applications over the WAN

Sending a single program remotely is possible and it works exactly the same as we’ve described, provided you allow remote ssh connection into the network/machine where you want to access the desktop PC or server. Only the ssh port needs to be open, not the X/Windows ports, if you use the ssh-tunnel method.

Remote Desktops

Do you still want the entire remote desktop? Perhaps you have a low powered netbook (running some version of Linux) and want to use the processing power of your desktop back at home or in the office. You’d like the entire desktop to be displayed remotely. Perhaps you have a desktop upstairs and a notebook PC in another room. Remote control of the other system is handy.

VNC uses DISPLAY too

If you’ve ever used VNC to display a remote desktop, you’ve noticed how the DISPLAY has a funny setting? It is using the normal X/Windows control method.

Remote Desktops via XDMCP

X has XDMCP built in. This protocol is a way to remote into a server or another desktop. Basically, the user will see the exact same screen as they would sitting behind the console, starting with the login GUI. This protocol is often used for time shared systems or remote GUI terminals in a corporate environment. Because it isn’t very efficient, other options have been created like VNC, RDP, NX and proprietary solutions from Citrix, NEC and others. On a LAN, you can play with XDMCP

RDP on MS-Windows

“RDP” – Remote Desktop Protocol is used mainly by Microsoft, but others do as well. In Vista or Win7, MS added more security to RDP and broke most of the free implementations, unless you force the RDP server to allow insecure connections. Further, RDP is not included in MS-Windows-Home versions (look for Remote Desktop in the help on Professional or greater versions).

VNC

VNC is a remote desktop protocol created by AT&T Labs. There are multiple implementations each with pros/cons. To my knowledge, they are all interchangeable and work with each others’ servers. VNC is the free alternative and used extensively on Linux systems and for virtual server access.

Both VNC and RDP are used for remote desktops.

If you truly want a remote desktop and you are in a mixed environment, then VNC is the easiest to use. Personally, I believe that RDP is a little more network efficient than VNC and it seems to do a better job following the mouse pointer. That doesn’t mean that VNC isn’t nice too.

NX – A Newer, Efficient Answer

The NX protocol, (FreeNX) http://en.wikipedia.org/wiki/Freenx gets high marks for being much more efficient than either RDP or VNC AND it includes encryption. Here’s a FreeNX guide from Ubuntu – I just followed it and have a remote desktop working over the WAN using my own ssh-keys (not the NX generated keys). It took about 10 minutes to get everything setup and mostly working following the guide. I used the FreeNX server and qtnx client on my local laptop. Some keyboard translations didn’t work correctly – the pg up/down and other special buttons caused strange things to happen inside OpenOffice. I didn’t do any trouble shooting at all. I did specifically use my WAN (ISP connection) for the access. It was very good.

Video playback over NX was extremely jumpy and there wasn’t any sound at all. I believe media playback is where the commercial offerings shine for RDP, NX, Citrix, and VNC.

99% of the time, I use `ssh -X` to remotely start remote applications and have them displayed on my current machine. It works best over a LAN, but I’ve used it over 14.4Kbps dial up links too. THAT was painful. Having an entire “remote desktop” seems like overkill to me, but I’m very comfortable on a shell prompt.

Connecting to Linux from MS-Windows

There are X-servers that run on MS-Windows. I’ve used commercial and free solutions and generally found that running Linux inside a virtual machine was preferable for me. None of these programs are really ready for someone without X/Windows experience to setup and run. They always need an expert to help, IME. Anyway, here are a few other options, if you must: Xming, Cygwin/X, Chameleon, Exceed, Hummingbird. The last three are commercial and performed well. I used each for over a year in a work environment about 10 yrs ago. I think there has been consolidation in that market, so some of them have merged into a single vendor. Again, I prefer to use a Linux distribution running inside a virtual machine and remote into other systems for my X/Windows client/server needs. It feels more natural to me.

Connecting to MS-Windows Desktops or Terminal Servers from Linux

Microsoft decided to deploy RDP for remote desktops. This is based on an older Citrix protocol and works well enough. The RDP, Remote Desktop, server is not built into Home versions of MS-Windows, but if you have Professional, Enterprise or Ultimate, then you can enable Remote Desktop Connection on Win2000, WinXP, Vista, Win7 and any Windows-Server OS. To access Windows7, I had to install rdesktop on my Linux machine, set the Win7 RDP server tool to an older, lesser security level, then connect:
a) On Linux: $ sudo apt-get install rdesktop
b) On Win7 Ult: Enable Remote Desktop with the older protocol version. This prompted me to open a firewall port on the Windows-side
c) On Linux: $ rdesktop -u {userid} -g 1280×1024 {win7-machine-name}

It worked. Just be aware that rdesktop is not considered secure and shouldn’t be used over Internet connections without going over a VPN or ssh tunnel.

NX Based Remote Desktops : 12/2014 Update

With newer releases support for the FreeNX tool appears to have lagged. I’d been using FreeNX almost daily for a few years and it worked well for business productivity applications from anywhere in the world. Used it on 4 continents and about 10 different countries, not to mention daily use inside the LAN.

In mid-2014, I switched to x2go and have been using it daily, all day, to access my primary desktop running in a private cloud. This is an NX-based solution, but handles video and audio much easier. There isn’t any extra setup on the server-side, it uses ssh-keys for connection authentication and an ssh-tunnel for all traffic. It has excellent performance.

By far, x2go is the best, most secure, remote desktop application available today for free. Only the commercial VDI solutions would be able to touch the capabilities, performance and security of x2go. I’ve used x2go on 3 continents and a few countries. It performs at least as well as FreeNX and has the same level of security, while adding support for remote audio. Remote video really only works on a LAN, not over the WAN.

The downside for NX/x2go is that a full desktop OS is required. No ports for iApple or Android exist. I travel with a $200 netbook and this works well. x2go has clients for Windows, OSX and Linux. The Windows and Linux versions work well. Don’t know about OSX version.

I tried to travel through Europe with just an android tablet a few years ago and got burned. Hotels were blocking most outbound ports and at the time, Android didn’t have enough tools for me to determine the root cause and figure a way around it. My current Acer C720 Chromebook with Ubuntu 14.04 does solve that issue. If I fly, the C720 goes (previously I used an Asus Eee). If I drive, I take a Dell Core i5 15inch laptop with more capabilities. Either works as a great remote access machine.

The choices for remote access can be boiled down to this:

• Use ssh for all text connections from LAN or WAN.
• Use X/Windows with ssh-X-forwarding for LAN GUI connections.
• Use x2go for all WAN GUI connections.
• There is little to zero need for VNC or RDP over the WAN anymore. Use NX from a WAN connection to get into the LAN, then use RDP to connect to any Windows systems internally. The double-remote-desktop performance is really excellent. Hard to believe, but true.

All of these options are based on ssh for thee real security, so be certain to secure the ssh connection.