-   Linux - General (
-   -   about xauth? (

Chowroc 05-21-2005 10:17 AM

about xauth?
There is a host S, and a client L, S has start X Window, and L doesn't. now I do this:
L$ xclock -display S:0 &
The window will be shown at S.

S# xhost -
to enable contrl list, the L will be refused the next time because it isn't on the list.

At last I want make a user on L could do this:
S$ xauth extract - $DISPLAY | ssh -l USER L /usr/X11R6/bin/xauth merge -
But it still be refused. What's wrong? Is there any problem of my understanding?

thank you.

jschiwal 05-22-2005 07:23 PM

I don't think that your initial statement is correct. A computer or terminal needs to have the x11r6 server running to be able to display the output on the screen. Also, without even a simple window manager, you will not have borders or menus displayed. ( I am referring to computer S now. ) The role of server/client is different than what many expect. The X11 server is what displays things on the screen, so it is the terminal machine running the server. The program running on the different machine is the client. Techically, both may need the server program running, but the remote machine doesn't need a window manager if it doesn't display anything.

There are security policies which may control the usage of xauth. Try reading /usr/share/doc/packages/pam/README.pam_xauth as well as the xauth man and info pages.
There is also a readme on x-windows access in the web site. The NSA site has an x-windows security how-to that you could probably find using google.

Chowroc 05-23-2005 01:52 AM

I know what you mean.

But here I just want to test the authorization mechanism of X, in this condition, X11 Server is on host S(in fact i have start Gnome), and the client program xclock is on L, and L does not start X.

Now I can run xclock at L but display the window on S, is that OK? But this make every user on L could access S's X server, How can I make that only one user on L could do this?

Thank you.

jschiwal 05-23-2005 04:37 PM

You need to read up on how your system controls this. For many distro's the use of xauth is controlled by PAM. I already refered to the readme document for this. Other distro's such as Slackware do not use PAM. Here you would need to manually merge the magic cookie from ~/.Xauthority on host L to the ~/.Xauthority on host S.

A user's .Xauthority file is only readable by the owner.

This howto may help.

A better way may be to use ssh with x-forwarding. The handing of the X-auth cookies and setting of $DISPLAY is handled in the background. I've only used ssh to run programs remotely. I have rarely pushed an output like that. I think I just did it once as an experiment. However, I've used ssh on my laptop to run a program on my desktop, while displaying the program on the laptop.

If you also want sound to be played on the remote rather than the local machine, there may be more work and setup for this.

jschiwal 05-23-2005 08:41 PM

Here is another link.

It explains what may need to be edited to your startx scripts to allow using xauth.

/usr/bin/X11/xauth add :0 . $(dd if=/dev/urandom count=2 2> /dev/null | md5sum)

exec /usr/bin/X11/X -dpi 100 -nolisten tcp -auth $HOME/.Xauthority

The highlighted portions are new. This is based on a debian distro, but probably would apply closely to your situation ( unless your setup already has this in place )

Chowroc 05-24-2005 06:30 AM

"merge the magic cookie from ~/.Xauthority on host L to the ~/.Xauthority on host S", but when I do this on console:
L$ xauth nextract - $DISPLAY
xauth: (argv):1: bad "nextract" command line

Then I run X and xterm on L:
xterm$ xauth nextract - $DISPLAY
No matches found, authority file "-" not written

xterm$ xauth nextract ~/.Xauthority $DISPLAY
No matches found, authority file "/home/USER/.Xauthory" not written

What's wrong?

Still thank you, jschiwal

jschiwal 05-24-2005 05:21 PM

You may have better luck following these instructions. I don't think you are transfering the cookie information from the S host to the L host.


Giving another machine access

Set up .rhosts
To allow connections from another machine, first set up an .rhosts file on the remote machine. You've probably already done this before even thinking about figuring out xauth, but it's still important. The .rhosts file should contain the name of the local machine and your username on one line, separated by a space. This is the same file that you use to enable rsh, rlogin, and rcp. For more information on .rhosts files, see "help rcp".

Transfer the cookie
To transfer the cookie to a remote machine, set up the .rhosts file on that machine as described above, then type (replacing "remote" with the name of the remote machine you want to use):

local% xauth nextract - $DISPLAY | rsh remote xauth nmerge -

If your login name is different on the remote host, use:

local% xauth nextract - $DISPLAY | rsh remote -l username xauth nmerge -

All times are GMT -5. The time now is 07:04 PM.