Displaying X from remote machines
Introduction
This document tries to explain how to run X applications on remote machines displaying to machines in DAMTP, and answer some of the more common questions about X authentication. Some of the statements in this document are simplified to make them easier to explain, please don't complain about these simplifications.
If you need more detailed information, please contact the departmental computing helpdesk.
Use SSH where possible
The ssh protocol supports what is known as X-forwarding which arranges for the X protocol to be transported automatically over the strongly encrypted SSH connection.
The DAMTP ssh clients are mostly configured to enable X-forwarding by default, though on the MacOSX machines this isn't the case.
Sadly the authors of openssh decided to change the option to enable (normal) X-Forwarding from -X to -Y for version 3.8 with -X now meaning a new kind of X-Forwarding which will work with most applications but by no means all. See openssh FAQ 3.13 for some more information.
Therefore for newer versions of openssh use -Y, and switch to -X if that isn't recognised. e.g.
For openssh 3.8 or laterssh -Y mylogin@remotehost.mydomain.netFor older openssh (up to 3.7)ssh -X mylogin@remotehost.mydomain.net
The locally added slog command opens a new xterm and runs ssh inside it. This is just for convinience if you want a new window.
To tell if X-Forwarding is enabled and working you can check if the DISPLAY environemnt variable gets set when you have logged in. Traditionally it gets set to something like localhost:NN where NN is 10 or more. On some platforms it may be different for technical reasons.
Some sites configure their ssh servers so that X forwarding is not permitted. If you need to use X applications from such a site you will need to contact the administrators there for advice.
In very rare cases the minor overhead of going through the ssh tunnel may cause X applications to behave slowly. If this is a problem please seek expert help.
For more information about ssh please read the ssh in DAMTP page.
If the remote site doesn't support SSH
Since early 2003 the CMS site firewall has not permitted (non-ssh) X connections to machines, so none of this will actually work, but is left here for historians to wonder about.
If the remote system does not support ssh then you will need to arrange to:
- pass the x-authentication to the remote system
- log in and set DISPLAY accordingly
All our machines which run X use a method of authenticating X applications involving a secret key (cookie) which is generated for each session when you log in. This cookie is remembered by the server, and stored in a file (.Xauthority) in your home directory, and is used by all X applications to show the X server that they have permission to connect.
Can't I just use xhost?
The xhost command is a simple way to add machines to the list allowed to talk to a server.
That is it allows anyone who can use that machine to talk to an X server. Clearly this is not a good idea if the machine in question allows several people to use it. Since we can't tell which machines can be trusted to be safe to use xhost with, we strongly discourage its use. The xhost command has been altered to refuse to allow machines to be added to the list.
So what do I need to do?
The correct way to authenticate a remote session is to copy the cookie the that host. We provide four commands which will help in doing this, they split into two groups.
The xpermit command takes the name of a host and using rsh copies over the appropriate cookie to that machine. Similarly the locally modified xon command has a special option -permit which likewise passes the cookie over before running the command you specified. This xon does all the tedious work of calculation an appropriate value for the DISPLAY variable and passing it through for the remote command. An example might be:
xpermit -user jim host.somedomain
and for xon:
xon host.somedomain -permit -user jim x-command
Once the cookie is transferred, you can use xon without the -permit option since the same cookie is used for all access in a given session.
In fact the default x-command for xon is xterm so leaving out the command e.g.
xon host.somedomain -permit -user jim
will start a terminal window onto the remote host from which you can start other applications. The name and title of this window will be the name of the hostname given to the xon command.
See the man pages for xon and xpermit for more details of the other options available, and how they work.
I can't use xon
Both xon and xpermit rely on rsh being permitted from hosts here to the remote site. That is you must have a .rhosts file at the remote site listing the hosts here (and username since they will probably be different), and that rsh is permitted by the administrators there.
Not all sites permit users to have .rhosts files or a site may block rsh in some other way. This means that xon and xpermit will not work. If the site tells you that you can't use rsh then the methods described above will all fail.
Fortunately there is another service which can often be used to run remote commands. Through less commonly used than rsh most servers will accept rexec connections. The rexec service is much like rsh except that it requires a username and password be sent to the remote host rather than relying on trusting hostnames in any file. Any site which permits telnet will probably accept rexec.
We have locally modified versions of xon and xpermit which use rexec, and these are called:
xronandxrpermit
They are used in just the same way as xon etc but prompt for a username and password which is used by the remote host to show that you have permission to log in. e.g.
xron host.somedomain -permit
will prompt for the username and password to use on host.domain and then pass the cookie over and run the command. If you use the -user option then it won't prompt for the username, just the password.
See the man pages for xron and xrpermit for more details of the other options available, and how they work.
I get a strange error
If you get an error message about xauth not being found, this is probably because it couldn't find the xauth command which is used to insert the cookie into the authentication file at the remote end.
Normally these commands assume that either the path to the X executables is on the default path given to remote applications or is in /usr/X11/bin (which is the most common location).
However, some machines have their X binaries in other locations and don't put this on the default path. In some cases you can modify your shell start-up files at their site to fix this, but not all shells permit configuration of the path given to remote commands, and some sites will not allow you to change the shell or the initialisation files.
To get round this, xon etc can be told to explicitly look in another location for X binaries on the remote host. This is done with the -xpath option. e.g. on a Solaris-2 system you might use:
xron host.domain -permit -xpath /usr/openwin/bin
which will add /usr/openwin/bin to the path before running xauth or other user commands.
Of course you need to get the correct path to use with this option. If you don't know then the system administrators at the remote site should be able to help.
If you get a message about No remote directory then this means that the rexecd on the remote machine couldn't change directory to your home directory. Assuming that you have a home directory there, this usually means that the permissions have been set on it such that root can't read your home directory (e.g. it is over NFS and their machines don't trust each other).
If this happens, I'd suggest making your home directory (on that machine) world readable (you can still protect the files/directories below it). If you don't know how to do this ask the system administrators there or here.
If you see any other strange error messages place mail them to the departmental computing helpdesk and we may be able to make other suggestions.
If all else fails try asking us for help, we may be able to come up with a mechanism which works, though clearly it may simply not be possible. All of this depends on what services are permitted by the remote site.