0

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
  • 322
  • 1
  • 5
  • 23
  • On modern X servers, `-nolisten tcp` is the default, so the first step is to make sure your X server on the local machine is started with `-listen tcp` (configure whatever your distro uses to start it, e.g. the display manager). – dirkt Sep 14 '19 at 05:48
  • I have the -listen tcp there. That’s why it works if I allow the machine with xhost – Adriano_pinaffo Sep 14 '19 at 11:51

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>
u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Damn, I swear I had tried before `xauth add`, but now that I tried again it worked. There are several issues (`xauth generate` expires, `xauth export` doesn't allow you to edit the file to remove `/unix` and `xauth merge`, `xauth extract` file cannot be read by the other user by default because of security issues of course) with it that I'm sure there are explanations for each one of them. But for now I understood how it works. Thank you – Adriano_pinaffo Sep 16 '19 at 22:32
  • If you want to automate it (and if you want to use shellscripting instead of Xlib API), your best bet is to use `xauth nextract` and replace the first three fields (which are address type, address length, address itself), and possibly the next two (display length, display itself). – u1686_grawity Sep 17 '19 at 04:24
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