Invalid MIT-MAGIC-COOKIE-1 key% WIDGET_CONTROL: Unable to connect to X Windows display: localhost:11.0

Question

I am trying to run IDL from remote in terminal window. I would like to produce an image in a png file from remote without the pop-up window in my terminal (for some reasons that I do not know pop-up window plots do not work well in my computer). I have been using both ssh -X and ssh -Y and received the same errors. The script is as follows

set_plot,'ps'
device,/color,bits=8,xs=80,ys=60
device,filename=‘test.eps'
loadct, 4
!p.charsize = 1.2
!p.color = 120
lfile = FILE_LINES(filename1)
openr,1,filename1
ar1=fltarr(6,lfile)
readf,1,ar1
close,1
Xcoord=ar1[0,*]

Ycoord=ar1[1,*]
h2d=hist_2d(Xcoord,Ycoord,bin1=5, bin2=5) 
h2d = CONGRID(h2d, MAX(Xcoord), MAX(Ycoord))
g0=image(h2d)
device,/close
end

When I launch this script.pro via .r script, I receive the error at the line g0=image(h2d) that is copied below

% Compiled module: $MAIN$.
% LOADCT: Loading table BLUE/GREEN/RED/YELLOW
% Compiled module: HIST_2D.
Invalid MIT-MAGIC-COOKIE-1 key% WIDGET_CONTROL: Unable to connect to X Windows display: localhost:11.0
% IMAGE: WIDGET_CONTROL: Unable to establish X Connection.
% Execution halted at: $MAIN$             42 /home/script.pro

I believe the line %Invalid MIT-MAGIC-COOKIE-1 key% WIDGET_CONTROL: Unable to connect to X Windows display: localhost:11.0 points to a different issue than the line % IMAGE: WIDGET_CONTROL: Unable to establish X Connection.

Following the suggestions at (a similar Stackexchange question)[https://unix.stackexchange.com/questions/199891/invalid-mit-magic-cookie-1-key-when-trying-to-run-program-remotely], I tried to troubleshoot as follows but have not solved the issue:

1. The DISPLAY environment variable seems correctly set up: env | grep DISPLAY gives DISPLAY=localhost:11.0
2. The line export DISPLAY=desktop:0. gives error export: Command not found.
3. The line xhost +local: before running it gives Invalid MIT-MAGIC-COOKIE-1 keyxhost: unable to open display "localhost:11.0.
4. I tried also ps aux | grep bin/X | grep -v grep and receive

root      1745  0.0  0.1 323536 22172 tty1     Ssl+ Feb06   1:43 /usr/bin/X :0 -background none -noreset -audit 4 -verbose -auth /run/gdm/auth-for-gdm-DUUgHB/database -seat seat0 -nolisten tcp vt1

5. I tried also ps aux | grep /Xorg | grep -v grep and receive

root       758  0.0  0.0 225860  2872 ?        Ss   Feb06   0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD

When I try to run the same script from another computer, (connecting again via a terminal window to the same remote machine), I do not receive the line %Invalid MIT-MAGIC-COOKIE-1 key% WIDGET_CONTROL: Unable to connect to X Windows display: localhost:11.0, but I still receive % IMAGE: WIDGET_CONTROL: Unable to establish X Connection.

So I think the MIT-MAGIC line is a visualisation problem of my computer but I cannot debug the widget_control error anyway. If I could at least solve the widget problem, I could maybe produce the plot on another machine. Thanks.

Thank you so much for the thorough explanation, telcoM. Something is more clear to me now. I have re-installed XQuartz on my Mac (XQuartz 2.7.11). The error on MIT-MAGIC-COOKIE seems to have disappeared but I receive with the same script an error related, I think, to IDL libraries (execution haled at the same line as before, namely the image command):

% Compiled module: $MAIN$. 
% LOADCT: Loading table BLUE/GREEN/RED/YELLOW 
% Compiled module: HIST_2D. 
libGL error: No matching fbConfigs or visuals found 
libGL error: failed to load driver: swrast 
% Loaded DLM: PNG. 
% WIDGET_EVENT: Failure to acquire window rendering context. 
% IMAGE: WIDGET_EVENT: Unable to acquire device context. 
% Execution halted at: $MAIN$

An Idl pop-up window opens (black) and the saved file (45 kb) is a (blank instead) page. Googling led me to https://www.l3harrisgeospatial.com/Support/Forums/aft/4922 but I do not have access to IDL libraries. Should I ask the system administrators to change the IDL preferences?

Answer 1

In order to be able to display X11 graphics, a Mac needs to have XQuartz installed. This is the X11 display server: effectively, the canvas on which local and remote X11 applications can paint their display windows. Apple has set it up so that a Mac SSH will set up the X11 forwarding, and XQuartz will usually start automatically if it's not already running when needed.

XQuartz used to be part of MacOS, but is now a separate open-source project.

When a SSH connection with X11 forwarding is established, two things should happen at the remote end:

1. The remote sshd will set up a X11 proxy (normally allowing local connections only) to the first free TCP port number at 6010 or above, and set the DISPLAY variable to localhost:<port number - 6000>. This tells the remote X11 applications where to find the connection to the actual display.
2. The remote sshd will generate a MIT-MAGIC-COOKIE for the X11 applications to use, and will place it to a file to allow the clients to use it (usually by using the xauth command on the remote system). The default path for this file is ~/.Xauthority, but a custom path can be used if the full pathname is then also set into XAUTHORITY environment variable. If a X11 client cannot find or access this file, it won't be able to connect. A new cookie is generated for every connection: an old cookie file won't work.

On a Mac system with no XQuartz, it is possible to have this kind of problem, where the X11 application's error messages can be a bit misleading. The application has read the DISPLAY variable and successfully connected to the local TCP port 6011 according to the variable's value, and found the Xauthority file and is presenting the cookie to what it thinks is the real X11 display server (but is actually the remote sshd's X11 forwarding proxy). At that point, the remote sshd forwards the first X11 request to your local system through the encrypted tunnel, and the local end finds the actual XQuartz display server is... not there.

The X11 protocol does not have an error code that could effectively say "I'm sorry, I'm not the actual server; I'm just a proxy, a go-between. The actual server does not seem to be responding." Since the error is detected when first trying to use the cookie, a generic Invalid MIT-MAGIC-COOKIE error message is produced instead.

Regarding some of your troubleshooting steps:

The line export DISPLAY=desktop:0. gives error export: Command not found

This suggests the shell configured for the remote user account might not be one that uses POSIX sh syntax. But setting a DISPLAY environment variable this way means skipping the SSH tunnel and telling the X11 applications to make a direct unencrypted TCP connection to the X11 display server in port 6000 on host desktop. This is not secure and many modern X11 display servers won't listen for TCP connections at all, or at least will only listen for connections coming from the local system only. It is possible to make this insecure legacy method work by taking special steps, but you don't want to do that.

The line xhost +local: before running it gives Invalid MIT-MAGIC-COOKIE-1 keyxhost: unable to open display "localhost:11.0.

The xhost command can only be used if you already have a valid connection to a X11 display server. It can be used for one user to "open a door" for other users to connect to the same display, which may be useful if you need to use su or sudo on the remote host to switch to another user account before running GUI programs, but it allows everyone who can access the port/socket identified by the DISPLAY environment variable to access your display server. You don't want to do this unless you absolutely have to, and if you don't already have a valid X11 display connection in the first place, this won't help you at all.

I tried also ps aux | grep bin/X | grep -v grep

This indicates that there's a X11 display server running for the remote system's own display - it is not needed for the remote X11 application to get its display to you. If you had the authorization to use it, your image window would pop up onto the remote computer's display, which is presumably too far away from you to be useful.