Controlling Linux Remotely With X11 - page 4
X11 does try its best to be efficient with the amount of network bandwidth it uses. But there is always room for improvement. X protocol compressors like xdpc attempt to improve use of bandwidth over slow links. xdpc runs on the client and server ends. It is configured to appear to the clients as an ordinary server and to the server as an ordinary client. The compression takes place over the link by matching commonly occurring patterns. See http://ccwf.cc.utexas.edu/~zvonler/dxpc/README for more details.
XDM login or ssh?
As well as the methods mentioned above there are two other techniques for bringing up the link between client and server, XDM and ssh. They are quite different in concept so let's look at them separately.
XDM is a method of allowing a login just like the login prompt you see on your Linux box at boot up. The difference is that it can work over the network if necessary. If you have installed your Linux system so that you go straight into X you are almost certainly already using XDM to login! The XDM system picks up connection requests from X Displays and then gives them a "Login: Password:" challenge screen. If the user at the other end of the link types in the correct password then login is allowed. The login starts a new Xsession. To connect to an XDM you will need a working X Windows setup at the other end. There are some X Windows programs for MS Windows like Exceed or for the Mac like MacX. But we are interested in is Linux! To connect to a remote XDM server from a Linux machine with an X11 Server installed type in
X -query pants.internet.com
Where pants.internet.com is the domain name or IP address of the remote host that XDM is running on. After a few moments a login screen should appear. In testing this happened within 30 seconds on a 14.4k modem link. You may wish to use other options like 'timeout' or 'terminate'; see man Xserver for many more details.
XDM as a system is designed to work primarily on LANs, but as it uses Internet protocols, it will also work over long distances as well. Over public networks another networking problem becomes more of a headache: security. X windows does have some interesting security features. There is the 'xhost' system that keeps a list of domain names allowed to connect to a display. We saw an example of this above. In addition there are various authorization schemes that work with 'magic cookies' or 'tickets'. With these schemes XDM issues the magic cookies to the remote end, where the user is at login time. Each time a connection is set up, the cookie is checked to see if it is allowed. Some of these systems use public key encryption to make your 'magic cookies' more secure, but none of them encrypt the data passed; they only make setting up new connections safer. I will not examine these schemes in detail here; take a look at man Xsecurity if you think they sound interesting.
The program I most often recommend for overcoming networking security problems has to be ssh. X11 can also have its networking problems solved with ssh. In case you haven't come across it before, ssh is a system for allowing shell based communications between hosts over an authenticated and encrypted link. The authentication is similar in intent to the 'magic cookie' schemes that use public key encryption. This authentication means that it is very difficult for ssh communications to be faked. The encryption means that no one can eavesdrop on what you are saying. Encrypting all the data on the link is a big improvement on what XDM has to offer.
Like dxpc (described above) ssh works by impersonating an Xserver that is in turn acting as a proxy for the real X Server. What happens in practice, though, is quite transparent to the user. The DISPLAY variable is set automatically to the correct value to point to the proxy on the client end.
For instance to run the comical 'xeyes' program remotely you could type
ssh pants.internet.com -c 'xeyes'