shadow over ssh not working: Invalid MIT-MAGIC-COOKIE-1 key

[ilia-kats]

Describe the bug
xpra shadow ssh:host stopped working since an upgrade to 4.4.5 today. The log on the server has over 94000 lines with Invalid MIT-MAGIC-COOKIE-1 key, followed by

2023-07-08 21:49:46,998 Error: failed to connect to display ':0'
2023-07-08 21:49:46,998  could not connect to X server on display ':0' after 3 seconds

The same happens with xpra 4.4.6. Running xpra shadow :0 locally works. SSH-shadow used to work on 4.4.4. however, since I ran a full system upgrade today, I'm not certain that this is an issue with xpra or with something else. General X forwarding works: I am able to run ssh -Y host followed by glxgears. Any pointers on how to debug this would be appreciated.

System Information (please complete the following information):

• Server OS: Arch Linux
• Client OS: Arch Linux
• Xpra Server Version 4.4.6
• Xpra Client Version 4.4.6

[totaam]

What is the correct $XAUTHORITY value that xpra is having to guess when logging in via ssh on your system?
(this varies from one distribution to another, display manager and DE, etc..)

[ilia-kats]

Thanks for pointing me in that direction. It seems that SDDM (my login manager) redesigned xauth handling in the new version, so it's now stored in /tmp/xauth_xxxxxx, where xxxxxx is a randomly generated string.

[totaam]

If that's the case then I don't know how xpra is supposed to guess which path to use!

[ilia-kats]

Perhaps try any /tmp/xauth_xxxxxx file that is owned by the current user? Would that be possible?

[totaam]

This could take a very long time if there are many, and timeouts are painful to handle.

[ilia-kats]

How about just the first one then? Realistically, the same user probably will not have multiple X sessions running, so that should cover the majority of cases.

[ilia-kats]

Alternatively, and as a general solution that should work everywhere, one could first get a list of all processes by the current user, then for each process look in /proc/PID/environ if DISPLAY matches the display to be shadowed. If so, read XAUTHORITY from the same file.

[totaam]

Reading /proc is very much Linux specific (though it may work on some BSDs), this is sometimes blocked by security rules, and the DISPLAY environment may be set internally by the process rather than exposed by its parent.
I would prefer reading /tmp/ in last-modified order and setting a (configurable) limit on the number of tries.

[totaam]

@ilia-kats The commit above should work.

[ilia-kats]

Nope, now I'm getting

could not detect any live displays
2023-07-11 17:05:50,809 Error: failed to receive anything, not an xpra server?
2023-07-11 17:05:50,809   could also be the wrong protocol, username, password or port
2023-07-11 17:05:50,809   or the session was not found
2023-07-11 17:05:50,809 Connection failed

on the client (tried with current git master on both machines). On the server, all files in /run/user/UID/xpra have a timestamp from a few days ago, even the run-xpra script.

[totaam]

Please be specific. I have no idea what you did to get this output.

[ilia-kats]

Same as in the issue report: xpra shadow ssh:server.

[totaam]

For debugging, don't run the all-in-one ssh command, first login to your server then run shadow from there using:

xpra shadow

You may want to just print the files that it found here:
b601e60#diff-a6dc8b4189ec7f15245b7ba078320a323e9264fbc226c81a887174efe251054cR1143

If your xauth file looks like /tmp/xauth_xxxxxx then it should have been matched by:
b601e60#diff-a6dc8b4189ec7f15245b7ba078320a323e9264fbc226c81a887174efe251054cR1133

[ilia-kats]

running xpra shadow on the server over an SSH connection gives me could not detect any live displays. I tried adding some print statements in /usr/lib/python3.11/site-packages/xpra/scripts/server.py below line 1143, with no effect. I also tried throwing an exception on line 1115, also no effect. Editing the could not detect any live displays message in /usr/lib/python3.11/site-packages/xpra/scripts/main.py works, so it looks like it's aborting before server.py:1115 somewhere.

[totaam]

Ah, right.
So it cannot detect the live displays because it would first need to have the correct XAUTHORITY value.
That's harder to do.

[totaam]

@ilia-kats what does xpra displays show on your server?
Does it see the X11 server at all?

[ilia-kats]

$ xpra displays
Found 0 displays:

with Git master. However, with 4.4.5, I get

$ xpra displays
Found 1 displays:
  :0    UNKNOWN     uid=0, gid=0

(that's the version that threw the invalid MIT-MAGIC-COOKIE error)