1

I know the risk, I know there is ssh -X, etc etc. What I want is to be able from one remote machine (X client) to connect to my local machine (X server) on a user (cookie) basis.

I understood that any session using my cookie in ~/.Xauthority will be able to connect to my X server (got it from this). So, this is the scenario:

local machine (X server):

$ xauth nlist
<a bunch of numbers>
$ xauth nextract xauth-extracted :0
$ cat xauth-extracted | ssh user@<X client IP> xauth nmerge -

remote machine (X client):

$ xauth nlist
<2 bunches of numbers, the second one is identical to the one from my X server machine>

$ export DISPLAY=<X server IP>:0

$ xeyes
No protocol specified
Error: Can't open display: <X server IP>:0

On the X server machine, as soon as I allow my X client IP host $ xhost +<X client IP> and run xeyes again, it opens fine on the X server. But I don't want to allow it to all users, only to the one that is holding my xauth cookie. What am I doing wrong?

EDIT: I realized that extracting the :0 and merging into the other host and then listing the cookies gives me:

$ xauth list
<X server hostname>/unix:1  MIT-MAGIC-COOKIE-1  <hex key - the same as my X server hex key>

I don't know for sure what that /unix there means (unix socket I read somewhere) but that seems to have something to do with it.

To kinda make it works, on the X client I opened X connections to any host with xhost + and from the X server I ran xauth generate <X server IP>:0 .. That connected to the X server and downloaded not the cookie but a related (?) cookie, and now when I list the cookies it says:

$ xauth list
<X server hostname>:0  MIT-MAGIC-COOKIE-1  <another hex key>

An now it "works" but:

  1. After some minutes it stops working again
  2. If, from the same machine, I xauth generate a cookie for another user, the first one stops working

When they stop working they say:

$ xclock
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: <X server IP>:0

Can anyone point me to a good resource regarding xauth?

Adriano_pinaffo
  • 262

2 Answers2

0

The xauth entry needs to have the correct hostname – it needs to match what you have in $DISPLAY – otherwise Xlib clients simply won't be able to find it.

As you noticed, the local xauth entry just has the system hostname + /unix, and it's selected whenever clients have a $DISPLAY with no host, so they connect through a local socket (located in /tmp/.X11-unix/X0).

However, your remote clients are told to connect to <X server IP>:0, so that xauth entry will obviously no longer match. They want the xauth entry to be for the address found in $DISPLAY, i.e. <X server IP>:0.

This means you cannot use nextract/nmerge easily (unless you edit the 'hostname' field in the extracted data); for a one-time experiment it'll be easier to copy&paste the cookie manually:

xauth add "$DISPLAY" MIT-MAGIC-COOKIE-1 <hex key>
grawity
  • 501,077
0

Just to add some more clarity about xauth generate command. Based on man xauth it has such parameters: 

generate displayname protocolname [trusted|untrusted]
           [timeout seconds] [group group-id] [data hexdata]

Where

The timeout option specifies how long in seconds this authorization will be valid. If the authorization remains unused (no clients are connected with it) for longer than this time period, the server purges the authorization, and future attempts to connect using it will fail. Note that the purging done by the server does not delete the authorization entry from the authorization file. The default timeout is 60 seconds.

And based on example from p.186 in "X Power Tools" book by Chris Tyler to create a cookie without expiration time you should set timeout to 0, i.e.

xauth generate <X server IP>:0 . timeout 0

You should notice that untrusted cookies allow to run software accelerated X applications, but gives no access to hardware acceleration with error like this:

ubuntu@mycontainer:~$ glxdemo
Error: couldn't get an RGB, Double-buffered visual

Possibly it can be bypassed by VirtualLG software, however, it has yet to be checked (and not related to an answered question).

diabolusss
  • 1