Drop xauth dependency / custom cookie creation

[mviereck]

Hello @eine ,

are you still using x11docker and runx?
Once we had the issue that MSYS2 does not provide package xauth so x11docker and runx could only run with option --no-auth.
These days I managed to create a cookie file without the need of xauth.
I'd like to implement this in runx and want to ask you if you could test it if it works.

[esaulenka]

I am using runx on MSYS2 (without auth, sure). Thanks for this app, running remote applications via SSH -X (or -Y in my case) without additional Linux virtual machines is very useful.
And I am able to do some tests if needed.

[mviereck]

Thank you for your offer to test!
I have commited a new version that creates a cookie without xauth. Please run a test without option --no-auth in MSYS2.

[esaulenka]

I run your latest script (this one #8 (comment) ), but bash on MSYS (and google too :) ) doesn't know, what is the strlenhex and makecookie.

$ ./runx.sh
telnet: Unable to connect to remote host: Connection refused
runx note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings.
  Compare:   https://github.com/mviereck/x11docker/issues/108

runx note: If you get application error messages like 'Cannot open display'
  or 'Invalid MIT-MAGIC-COOKIE', the X authentication cookie might be broken.
  You can remove old cookies and stop running X servers with: runx --cleanup

DISPLAY=192.168.56.1:1 XAUTHORITY=/home/alexeye/runx_Xauthority
./runx.sh: line 456: strlenhex: command not found
./runx.sh: line 458: makecookie: command not found
awk: cmd. line:5: warning: no hex digits in `\x' escape sequence

[mviereck]

I run your latest script (this one #8 (comment) ), but bash on MSYS (and google too :) ) doesn't know, what is the strlenhex and makecookie.

Ooops, I forgot to include some subfunctions.
I've added them to the script, please update and try again.
I've taken the code from x11docker.

[mviereck]

It would be nice if you could test again.
I feel uncomfortable to have a possible broken version online.

[esaulenka]

Sorry, I was busy with my work tasks.

I did some tests, but unfortunately I could not get it to work.

First, I found issue with convertpath(). For some strange reason, MSYS uses C:\msys64\home\username instead of standard Windows C:\Users\username. You can use cygpath utility to convert (as I see, you already use it sometimes). It is always included in MSYS installation. So, in my case there is two copies of same runx_Xauthority: in ~ and in %HOME%.

Then, I found that your cookie have a strange form. As I see on stackoverflow, address field should contain hostname in ascii form, but you put there 4 bytes - IP in binary form.

Third, I found ready to use xauth in a VcXsrv. When I did alias xauth=/C/Program\ Files/VcXsrv/xauth.exe runx will run it. So, you can simply check for it and use when possible.
But even in this case xeyes on remote machine cannot find display...

[mviereck]

Thank you for the tests!
It seems introducing the custom cookie has more issues than I expected. At first I thought it would just work and only needs confirmation.

For now I've added a message that the custom cookie is experimental and one might use --no-auth if it fails.

First, I found issue with convertpath(). For some strange reason, MSYS uses C:\msys64\home\username instead of standard Windows C:\Users\username. You can use cygpath utility to convert (as I see, you already use it sometimes). It is always included in MSYS installation. So, in my case there is two copies of same runx_Xauthority: in ~ and in %HOME%.

x11docker creates two cookie files with the same content, one for the X server and one for the X client.
VcXsrv should use the cookie file in %HOME%, the client, in your case ssh -Y, should use the one in $HOME of MSYS2.
The --verbose output should show you the 2 cookie pathes, the one with $HOME is estimated with cygcheck.exe.

For some strange reason, MSYS uses C:\msys64\home\username

MSYS2 simulates a Linux environment, so this is consistent behaviour. And one might not want Linux config files in Windows' %HOME%.

Then, I found that your cookie have a strange form. As I see on stackoverflow, address field should contain hostname in ascii form, but you put there 4 bytes - IP in binary form.

I found this syntax by looking at cookie files with hexedit. I don't know a documentation for this behaviour.
xauth uses this syntax if DISPLAY has the form IP:DISPLAYNUMBER. If DISPLAY has the form :DISPLAYNUMBER, it stores the ascii hostname.
Example: xauth -f ~/mycookie add 127.0.0.1:100 MIT-MAGIC-COOKIE-1 $(mcookie) (4 byte IP)
Example: xauth -f ~/mycookie add :100 MIT-MAGIC-COOKIE-1 $(mcookie) (ascii hostname)

It might be worth a try to create a cookie $(hostname)/unix:DISPLAYNUMBER. I've changed the code accordingly. Maybe this helps. As it seems, only the final cookie code part itself and the display number are essential for authentication.

Third, I found ready to use xauth in a VcXsrv. When I did alias xauth=/C/Program\ Files/VcXsrv/xauth.exe runx will run it. So, you can simply check for it and use when possible.

I once tried xauth from VcXsrv and had a lot of issues with it. So I gave up to use it. Yet I don't remember the details, a related ticket is mviereck/x11docker#160.

But even in this case xeyes on remote machine cannot find display...

The exact error message is important at this point.

• Something like "Cannot open display" indicates that variable DISPLAY is wrong or the X server is down. (If you run runx with option --desktop, you can immediately see if the X server is running at all.)
• Something like "No protocol specified" indicates an authentication issue. Than it's either a wrong XAUTHORITY variable or a broken cookie file.

It might help to run runx --cleanup before every test run to stop all running instances of VcXsrv and Xwin and to delete the cookie files. Sometimes the cookie file is damaged for unknown reasons and causes startup failures.

[esaulenka]

oh, I completely confused :(

now I just did simple tests with your latest app:

$ source /usr/local/bin/runx --ip 127.0.0.1 --display 123 --verbose
....

$ echo $DISPLAY $XAUTHORITY
127.0.0.1:123 /home/alexeye/runx_Xauthority

$ hexdump -C $XAUTHORITY
00000000  ff ff 00 11 41 6c 65 78  65 79 45 2d 31 31 38 30  |....AlexeyE-1180|
00000010  2f 75 6e 69 78 00 03 31  32 33 00 12 4d 49 54 2d  |/unix..123..MIT-|
00000020  4d 41 47 49 43 2d 43 4f  4f 4b 49 45 2d 31 00 10  |MAGIC-COOKIE-1..|
00000030  e3 96 2a b4 ae fb d8 31  56 95 55 65 d0 04 78 d3  |..*....1V.Ue..x.|
00000040

$ ssh -XC ubuntu-vm xeyes
xxx's password:
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Error: Can't open display:

$ ssh -YC ubuntu-vm xeyes
xxx's password:
Warning: No xauth data; using fake authentication data for X11 forwarding.
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: localhost:11.0

so, it didn't working even with Y option in SSH.

$ source /usr/local/bin/runx --ip 127.0.0.1 --display 123 --verbose --no-auth
....


$ ssh -YC ubuntu-vm xeyes
xxx's password:
Warning: No xauth data; using fake authentication data for X11 forwarding.

but here it works fine

[mviereck]

oh, I completely confused :(

You have a close look on what is happening and I appreciate that!

$ echo $DISPLAY $XAUTHORITY
127.0.0.1:123 /home/alexeye/runx_Xauthority

$ hexdump -C $XAUTHORITY
00000000 ff ff 00 11 41 6c 65 78 65 79 45 2d 31 31 38 30 |....AlexeyE-1180|
00000010 2f 75 6e 69 78 00 03 31 32 33 00 12 4d 49 54 2d |/unix..123..MIT-|
00000020 4d 41 47 49 43 2d 43 4f 4f 4b 49 45 2d 31 00 10 |MAGIC-COOKIE-1..|
00000030 e3 96 2a b4 ae fb d8 31 56 95 55 65 d0 04 78 d3 |..*....1V.Ue..x.|
00000040

This looks well so far.
Could you compare with the cookie file in %HOME% if it shows any difference?

I have the impression that ssh does not find the cookie file, maybe due to path conversion. I can reproduce the error messages on Debian if I set XAUTHORITY to non-existing or empty files:

$ XAUTHORITY=/nonsense ssh -Y localhost -- xeyes
Warning: No xauth data; using fake authentication data for X11 forwarding.
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: localhost:10.0

$ touch nonsense

$ XAUTHORITY=~/nonsense ssh -Y localhost -- xeyes
Warning: No xauth data; using fake authentication data for X11 forwarding.
Invalid MIT-MAGIC-COOKIE-1 keyError: Can't open display: localhost:10.0

However, hexdump finds the file in variable XAUTHORITY, so why should ssh have an issue here?
I am a bit clueless now.

[mviereck]

Just an idea: Maybe IP 127.0.0.1 is an issue.
Try without setting option --ip and use the IP provided by runx.