[plug] Forcing X server to allow user to start programs remotely after login

[James Devenish]

Hi,

X11 is governed by certain authorisation mechanisms, which are important
for preventing hijacking and eavesdropping. Since these authentication
mechanisms are well defined, there is no need to `force' the server to
do anything unusual. The details of what you want to achieve are not
clear, as I don't know how it is that programmes are being invoked on
the 'remote' (non X-server) machine nor how it is that your users are
logging in to the remote machine. We also don't know the nature of the
environment (e.g. is it a LAN with two users and no Internet connection,
or is it a vigorous multi-user Internet-connected environment).
Nevertheless, here are some ways of playing the game on a personal
basis: 

1/ xhost (address-based authorisation) is a last resort. Do not use it
in a multi-user networked environment.

2/ If TCP is not enabled for your X server (i.e., the computer that is
displaying the X desktop), I am not sure what you can do. However, I
assume that OpenSSH X11 Forwarding would do the trick. OpenSSH X11
Forwarding is also the easiest approach for a regular UNIX users, and is
perhaps the best option if the network connection between your remote
application server is not otherwise secured. Basically, you log into a
remotehost from your xdisplayhost and when you run a programme on
remotehost it will get displayed on xdisplayhost. This relies on both
the SSH server (i.e., remote host) and the SSH client agreeing that X11
Forwarding is enabled. OpenSSH ships with Forwarding prohibited. Once it
is enabled, you would do this:

xdisplayhost% ssh -X -f remotehost xterm -title remotehost

This would demonstrate that xterm, running on remotehost, can be
displayed in the X session on xdisplayhost. What OpenSSH has done is set
up some credentials in remotehost:~/.Xauthority and opened a listening
port on remotehost's loopback interface, and set remotehost's shells'
DISPLAY variable to point to the loopback port. xterm then connects to
the lookback port using the .Xauthority credentials, and its connection
is forwarded to xdisplayhost, where it gets authorised and displayed.

3/ If TCP is enabled for your X server and if your xdisplayhost and
remotehost share home directories, your remotehost can instantaneously
display things on xdisplayhost. This is because the user who logs in to
xdisplayhost will have an ~/.Xauthority file (created automatically),
and programmes on remotehost can therefore be invoked like this:

remotehost% export DISPLAY=xdisplayhost:0
remotehost% xterm

xterm on remotehost will pick up the authorisation credentials from
~/.Xauthority, and these will be accepted by xdisplayhost. Note that
the traffic will not be encrypted, so it is exposed to network sniffing.

4/ If TCP is enabled for your X server, but xdisplayhost and remotehost
do not share home directories, you can prime each X session as follows:

xdisplayhost% xauth extract - $DISPLAY | ssh remotehost xauth merge -

This will set up the .Xauthority file, and thereafter everything is done
as in section 3:

remotehost% export DISPLAY=xdisplayhost:0
remotehost% xterm

5/ If none of these is suitable for your application, you should
probably look at the xauth manual and Google. Perhaps you can set up
some sort of unique static cookie for each user, and replicate them
between all the hosts that need to share the display, and add any
appropriate values (e.g. the DISPLAY environment variable) to people's
shell startup scripts. I'm just guessing, and other people probably have
ideas too.