I am preparing to upgrade a bunch of systems running Rocky8.10 to Rocky10.1. We still have some legacy Xorg apps. They run fine on Rocky10.1, but sometimes I need to be able to ssh one of the Rocky8 systems, and run it there. This does not work. I know 10.1 is running Wayland (and Xwayland is installed). Rocky8.10 is running Xorg. What I really want to be able to do is ssh from Rocky10 to rocky8 system and run the app. When I do the ssh -X -Y rocky8 I get the error “Invalid MIT-MAGIC-COOKIE-1 key”. Of course I can’t run the app. Even if I ssh from Rocky10 to Rocky10 system, it also doesn’t work (though doesn’t generate the MIT-MAGIC-COOKIE error). It looks like this should be workable according to the RH docs, but it doesn’t work for me. Work for anyone else?
The “Invalid MIT-MAGIC-COOKIE-1 key” error when SSH X11 forwarding from a Wayland session is a known friction point. When your Rocky 10.1 session is running under Wayland, the XAUTHORITY file used by XWayland may not be the standard ~/.Xauthority location that SSH’s X11 forwarding mechanism expects.
Two things to try:
First, switch to trusted X11 forwarding. In your SSH config (~/.ssh/config) or on the command line, use -Y instead of -X, or add:
ForwardX11Trusted yes
The untrusted (-X) mode applies stricter cookie checks that frequently fail in Wayland/XWayland environments. Trusted (-Y) bypasses some of that.
Second, check what DISPLAY and XAUTHORITY are set to in your Rocky 10 terminal before you run the ssh command:
echo $DISPLAY
echo $XAUTHORITY
Under XWayland, DISPLAY is typically :0 or :1, and XAUTHORITY might point to something like /run/user/1000/.mutter-Xwaylandauth.XXXXXX rather than ~/.Xauthority. SSH’s X11 forwarding reads from XAUTHORITY to generate the forwarding cookie, so if it’s unset or pointing to the wrong file, the cookie won’t match what the remote expects.
For Rocky 8 → Rocky 10 direction: since Rocky 8 is running plain Xorg, that should be the simpler end. The issue is always on the Wayland side where the forwarding originates.
I enabled “ForwardX11Trusted yes” in /etc/ssh/ssh_config
(Previously I had both ForwardX11Trusted set to yes and ForwardX11 but I commented ForwardX11 for now..)