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

[Timothy White]

James Devenish wrote:

>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: 
>  
>
Sorry for not making it clearer. Firstly it is on a private LAN between 
numerous computers. Basically I want to be able to ssh into the terminal 
from any computer and run programs on my Xsession on the terminal server.
E.g.
Login in to Xserver locally or with XDMCP so that the Xserver is running 
on the server and all applications are on the server.
Then from another computer ssh into the server that is running the 
Xsession and start a new program that will display in my Xsession.

>1/ xhost (address-based authorisation) is a last resort. Do not use it
>in a multi-user networked environment.
>  
>
I believe that xhost also does user authentication IF they are local. 
e.g. 'tim@' would allow or deny the local user 'tim' access to the Xsession.

>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.
>  
>
^^ This one appears to be in the wrong direction as do some of the ones 
below.

>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.
>  
>
I don't mind having to export the DISPLAY myself, its the xhost at 
startup that I need to work out.
Tim

-- 
Tim White
PGP/GPG id: 602E944D, Pub Key Serv: subkeys.pgp.net
Fingerprint: 04C2 9682 B7B2 3006 009D  A9F3 067E EDCD 602E 944D
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20041107/4de048dd/attachment.pgp>