Introduction
There are a few ways to run X windows applications remotely (running an Xwindows application on a remote computer and having the graphical part show up on your local computer). For something quick use the SSH method. In order to set up a barebones terminal on a old machine (that logs into a central server) consider Sterminal below. I include XDMCP below for completeness, but I can NOT think of a reason when that would be used over the other methods described here.

UPDATE: Before trying these options below give VNC (aka RFB) some consideration (even for dummy terminals). Seriously, I use it all of the time.

Important note: The old way to run x programs remotely was to use the "xhost" command. DO NOT USE THIS - IT IS NOT SECURE!

SSH
Let's say you are sitting at a computer (the client)... I'll call it "homecomputer". Suppose you are running some form of X windows on homecomputer. Then suddenly you decide that you need to quickly type up a document on your computer at work (we'll call that computer "workcomputer"). But you're not SITTING at workcomputer!

Try logging in remotely (using ssh, of course) to workcomputer with the -X switch, like so:

ssh -X workcomputer

That should log you into workcomputer. The -X switch says to export graphics from the remote computer (workcomputer) to the computer you at actually sitting on (homecomputer).

Now you can just run your program. For example, if I'm typing up something, I might be using "kwrite", so I'd just type

kwrite

This will run kwrite on the remote machine (workcomputer), but the graphics will display on the local computer (homecomputer). Note that any files saved will be saved on the remote computer!!!

Note that in order to ssh into workcomputer, the daemon sshd must be running on workcomputer (i.e. something must be there to answer my request to log in). This daemon must also be configured to allow graphics to be exported. Usually this is the default, although on my Debian machines I found that I had to edit the file "/etc/ssh/sshd_config" on workcomputer and look for the line "X11Forwarding no" and change it to

X11Forwarding yes

Of course, then the sshd daemon must be restarted on workcomputer for the configuration to take effect.

One possibly cool way to do this sort of thing is to make use of the Linux Terminal Server Project (ltsp). This allows us to use the junkiest old computers as "dumb" X terminals - they don't even need hard drives! Just boot off of a floppy or eprom on the network card and away it goes. Even a crappy old 486 looks like a shiny new computer since the real work is happening on that shiny new server. But that's for another day... for now I recommend Sterminal.

First I'll explain the classical way using "XDMCP", which isn't secure since it sends your passwords over the network unencrypted. I suppose that you can still use this if you trust your local network, although there doesn't seem to be any point.

Server Configuration
Here I'll outline the use of XDMCP. Basically, on the remote computer (workcomputer) I need to be running a special daemon that answers requests to login. For just plain old X, this is called "xdm". For KDE, this is called "kdm". For Gnome, it's called "gdm".

It is worth pointing out that this method is not very secure. Your password will be sent over the network unencrypted. For a better alternative, see the "sterminal" option below.

These programs need to be configured correctly. First, they need to be told to accept windows login requests. For all of them, this is easy. You need to edit the file "Xaccess". The location of this file can vary widely. For xdm it is usually in "/etc/X11/xdm", while for kdm it can be in "/etc/X11/kdm" or "/etc/kde3/kdm" (in OpenBSD 3.6 it is stored somewhere else - more about that later). Use the command "locate Xaccess" to get the location.

Now there will be a line in there which reads "#* #any host can get a login window". You will want to uncomment this line (take out the first "#"). This means that ANY (* means any) host can connect. This is not very safe - really this file should contain an explicit list of machines that can get an X session from "workcomputer". You should figure out more about the "Xaccess" file by googling it.

Now, for xdm, I need to edit the file called "xdm-config" (usually in the same directory as "Xaccess". There are two lines of interest in there. The first allows authorization - you want that

DisplayManager*authorize true

Make sure this is exactly how it reads. If it is false, change it to true. If there is a bang ("!") in front of it, take it out. The second line is blocks remote X requests... so you want to comment that out

!DisplayManager.requestPort: 0

Make sure this is how it looks. I had to ADD the "!" in front in order to make it work.

OK, now what to do for kdm. We need to edit the "kdmrc" file. This is usually stored in the same directory as "Xaccess" (OpenBSD users keep your shirts on!). There is a segment in there that looks like

[Xdmcp]
Enable=true

Make sure that the "Enable=true" option is set (mine was set to "Enable=false", so I had to change it).

That's it. You will probably have to restart xdm/kdm/gdm/whatever in order for the configuration to take effect.

OpenBSD users must do something different for kdm. They need to GENERATE the kdmrc and Xaccess files. The program to run is "/usr/local/bin/genkdmconf". Then the kdmrc and Xaccess files will be sitting in the directory "/usr/local/share/config/kdm".

Hopefully the xdm/kdm/whatever daemon is now running on the remote computer "workcomputer" with the proper configuration (you should have set that up before you went home).

Client Configuration
Later that evening.... sitting at home, I want to make my "homecomputer" look just like my "workcomputer". So, from my homecomputer, sitting at a terminal...

(make sure X is not running. You might have to kill xdm or kdm because they may be running locally, which will just keep on restarting X - note that kdm/xdm running locally on homecomputer has NOTHING to do with kdm/xdm running on workcomputer)

...I type "X -query workcomputer". This tells X to start up, but instead of using the local machine X login, it tries to login to "workcomputer". Good, it should come up and be just as if you were sitting on your computer at work.

Annoying Terminology
Note that the terminology can be very confusing (so I have avoided it here) concerning the "client" and the "server" for X. This has to do with the ingenious design of X, which makes all of this magic possible. Needless to say, in this situation, the machine that I am sitting at will be running the "X server", and the remote machine at work will be running the "X client". This is exactly BACKWARDS from every other aspect of this situation. I am sitting on a machine at home, which is the "client", which is logging into the "server" which is at work. The remote computer at work "serves" out all of the applications, and frankly does all of the work. Even as far as xdm/kdm is concerned, the remote computer at work is the "XDMCP server" and the computer at home is the "XDMCP client".

Nevertheless, as far as X windows is concerned, the program "X" that you run locally at home is called the "X server" and the program "kdm" on the remote computer at work opens up an "X client" (even though it is an "XDMCP server"... annoying but true).

STERMINAL
This is my personal favorite, since it combines the security of the "ssh" method with the full control and automation of the XDMCP method. Basically, this uses ssh, but it's automated. Make sure that you can first run X programs using ssh before trying this program (see the ssh section).

You might want to SKIP TO my own "hacked" version of sterminal, since the following changes (and many more) were incorporated there already. I added some features and dropped some features. Use at your own risk.

If you are a purist, then have a look at this website for the original program - sterminal is written by Bryan Wright

http://ayesha.phys.virginia.edu/~bryan/projects/knoppix/sterminal/

Just download the software and unzip it. The five relevant files are called "sterminal.pl", "sterminal-lib.pl", "sterminal.xsession.tcl", "sterminal.conf", and "sterminal.gif" (you probably have to "tar jxvf configs.tbz" to get a couple of these fully extracted).

He made the software for knoppix, but it easily can be put on any unix I think. You need to make sure that you have "tcl/tk (wish)" installed, as well as the package "tix" (note: "tix" is not necessary for my hacked version). You will also need "expect", "expectk", "perl", and, of course, a (barebones) working version of XWindows (try the Debian package "x-window-system-core").

I had to edit the file "sterminal.xsession.tcl" on line 153 - there you will find a line containing the test "ssh_bin -C". You need to change this to "ssh_bin -CX". This just lets ssh run X programs through the secure "tunnel". Note that I experienced a problem with Sterminal crashing about every 3 minutes when I upgraded my version of "expect", so I was forced to make other changes (which I have forgotten now). Again, these are included in my hacked version.

My Hacked Sterminal
There were a *couple* of things that I didn't like about about Sterminal (plus Sterminal kept crashing - small bug), so I made some changes. Namely, I took out a couple of fancy things that didn't seem necessary. This allowed me to NOT need the package "tix". Also, I added a button which stays up and allows the user to kill the session. Furthermore I added an extra button at the login prompt which allows you to shutdown the terminal machine altogether.

This is useful to me since I can envision a number of users just working on dumb terminals. Although I would leave the server up, I'm not going to waste power by leaving the terminals up all night. This is just an easy way to log out and shut down the terminals gracefully. These "dumb" terminals would be minimal installs of linux - just enough to get on the network and have the BAREBONES X server (DO NOT USE WINDOW MANAGERS LIKE KDM/GDM/XDM WITH Sterminal).

Also, there were a bunch of "update over the internet" features, but I don't understand the point, so I just disabled everything. Mostly I did this because it was causing problems with OpenBSD.

You can download my hacked version here.

There is NO setup required on the server - that's really really nice. The following describes what you must do on the dumb terminal to get it to talk to the server - it's really quite easy.

To install it, you will need to create a directory called /usr/share/sterminal (as root, obviously) and unpack the tarball in there. Then you will need to create a link to the "sterminal" script by issuing the following command:

ln -s /usr/share/sterminal/sterminal /usr/bin/sterminal

Make sure that you have the required packages installed before you actually try to run it. In Debian the required packages (note that the versions will change in the future) are "tcl8.4", "tk8.4", "expect", "expectk", "perl", and "x-window-system-core".

Now you need to figure out how to actually RUN sterminal. There are two ways: the "manual" method and the "way you probably want it".

The "manual" method is really just so that an ordinary user (already logged into the local machine) can use sterminal to run X programs on the remote machine. First, you must be OUT of XWindows on the local machine - this means that if you are using a display manager like xdm/gdm/kdm (graphical login) then you (actually root) will need to kill that process.

Now you will need to run Sterminal just like you would normally run a window manager. This means that you need to edit your ~/.xinitrc file and change the "exec [windowmanager]" to "exec sterminal". Then sterminal will run by typing "startx".

The way that you probably want to run sterminal (if you are setting up a network of crappy machines as I envision) is to run sterminal BEFORE the users are forced to login to the local machine. Otherwise users get confused (first having to login to the local machine and then logging in AGAIN on the remote machine). Plus, this allows you to not be forced to set up users on the local crappy machine.

Just add the following lines to /etc/inittab (at the end):

x2:2:respawn:/usr/X11R6/bin/X
st:2:respawn:/usr/share/sterminal/sterminal.pl :0

Note that you might want to edit the /usr/share/sterminal/sterminal.conf file to reflect the configuration that you desire for the terminal. For example, you can change the default remote host to your remote server (rather than "localhost" as it is configured now). Also, you can change the xsession command - /etc/X11/Xsession seems to work OK if you have only a simple window manager on the remote machine (like fvwm or fluxbox) but you should use instead "startkde" or "startxfce4" or "gnome-session" if you want to start more complicated desktops (like most of us do). You can add a default user and/or default password if you have a public access system (I added the new variables "defaultuser" and "defaultpass" - use them wisely).

Please see the relevant documentation on the original sterminal page. I also added another new configuration variable to the sterminal.conf file. It is called "killcommand", and it is the command that runs when the button "Shutdown" is pushed (this is a new button that I added at the login prompt). For example, I set it to just "shutdown -h now"... this will just shutdown the dumb terminal box. You might want to change it to suit your needs. Furthermore, it is worth mentioning that every user can have his/her own configuration file located in "~/.sterminal.conf" if you prefer to run sterminal using the above "manual" method.

Finally, I have added two more configuration variables to sterminal.conf that will allow you to tunnel Sterminal through a gateway/firewall that may separate your local machine from the desired remote machine (using an SSH Tunnel). The first is called "sshport", and it controls the SSH port to which sterminal makes a connection (if you want to use the default then 22 MUST be written explicitly - I'm a very lazy programmer). The second is called "sshHostKeyAlias" - please see the SSH Tunnel article above to explain why you might need this option.

Update March 2006: Expect 5.43 broke the hell out of sterminal. Apparently a Tk shell ("wish") can no longer include Expect as a separate library. Now, if you want Expect statements in your Tk shell, then you should use instead the shell "expectk". So I fixed this (this is not that first time that upgrading "expect" has broken everything. GRRRRRRR!!!)

VNC (aka RFB) method
There is one final method (that I know of) for running X programs remotely - that is using the so-called VNC programs so popular in the Microsoft world. Don't DISCOUNT THEM YET!!! In fact, the VNC way of doing things can be VERY useful, especially if you need to SHOW SOMEBODY how to do something from a remote location. Combined with SSH Tunneling there is no reason why this method cannot be AS SECURE as anything. Furthermore, VNC is FASTER than any of the above methods... REALLY! So if you have to do some X task over a DSL or something, this is probably your best bet.

For more info give VNC a try.

Good luck with this.

This page has been visited   times since January 13, 2005