How fix errors "No X11 DISPLAY variable was set" and "An error occurred: Can't connect to X11 window server using 'x.x.x.x:0.0' as the value of the DISPLAY variable" in ssh sesion with X11 forwarding

I use Windows 10 as a working operating system but almost all the development operation and system architecture is done through Ubuntu and CentOS computers that I access by ssh, VNC or RDP as needed.

On my Windows 10 I have Xming installed which is a portable implementation of the Windows X system for Microsoft Windows operating systems to be able to "run" applications with linux remote SOs desktop UI like Ubuntu or CentOS on my Windows desktop having X11 forwarding enabled on the linux OS and specified in the ssh session. There are other solutions like Xming that I have not used but that I have read that works very well, such as VcXsrc.

To be able to have this enabled it is necessary to have the linux system configured to allow X11 forwarding, which is done by leaving the ForwardX11Trusted attribute with the value yes in the /etc/ssh/ssh_config file of the linux server:

ForwardX11Trusted yes

On the desktop computer where you want to have the application with UI displayed I must have raised Xming that will be in the windows 10 running application block that appear on the bottom right icon of the desktop:

And on the Windows 10 computer you must run the ssh command with the -Y or -X options. The -Y option is to perform "Trusted X11 Forwarding", and the -X option is the same but also compressed, therefore the use of one or the other depends on the network quality you have, being -X preferable for slower networks or with less available flow rate when being compressed communication.

When you run the "ssh -X user@servidorremoto" command and try to run an app with UI as a jmeter can cause the error:

No X11 DISPLAY variable was set, but this program performed an operation which requires it.

This is because Windows ssh, in this case Windows PowerShell when the -X is specified in ssh does not use a specific DISPLAY in the ssh session.

The logical solution is to specify the DISPLAY with the IP of the Windows 10 computer, such as:

export DISPLAY=192.168.1.123:0.0

When running jmeter again now you get the error:

An error occurred: Can't connect to X11 window server using '192.168.1.123:0.0' as the value of the DISPLAY variable.

If this occurs it is because Xming has been launched with the security options. To launch it correctly you must first stop Xming by right-clicking on its icon and in the context menu press "Exit":

And in the window that appears (appears behind the context menu but can be moved with the mouse) press "Exit":

Once stopped we launched Xming again via XLaunch by double ckick on the Xlaunch icon:

In the first window we specify "Multiple windows":

When we press "Next" in the following window we specify "Start no client":

When we press "Next" in the following window we specify "clipboard" and "No Access Control", confirming in the following window:

The problem was that "No Access Control" was not specified and therefore the session requires some security access management via MIT-Magic-Cookie-1 or XDM-authorization-1 via the . Xauthority of the linux user, which can be managed with the xauth command to add authorizations, list them, and delete them.

In this . Xauthority each time an ssh with X11 forwarding occurs with "Remote X11 authentication protocol" is generated for example in the case of MIT-Magic-Cookie-1 a different cookie for that connected DISPLAY, usually localhost:10.0, and increasing for each ssh session to localhost:11.0, and so on.

With Windows ssh I have not achieved, I do not say that you cannot open an ssh with X 11 forwarding with "Remote X11 authentication protocol" and that is why they give the commented errors.

In the case of putty, specifying "Enable X11 forwarding" with "Remote X11 authentication protocol" by "MIT-Magic-Cookie-1" this manages them properly and the ssh session is opened with a DISPLAY and authorization for X11 forwarding through a new cookie for that DISPLAY in your session. Therefore to use windows ssh are X 11 forwarding we run Xming with "No Access Control" and in the ssh session we specify in the DISPLAY the IP of the Windows where we want the UI of the application to be opened, as we specified.

Setting up X 11 forwarding with putty:

First let's check that now with xming raised without access control we can visualize in Windows 10 the jmeter app that is running on the remote Ubuntu by opening an ssh with X 11 forwarding specifying the -X option, and specifying as soon as a DISPLAY with the Windows IP is in session (export DISPLAY-192.168.1.123:0.0):

If instead of using windows ssh we use another ssh as putty, we configure X 11 forwarding with "Remote X11 authentication protocol" by "MIT-Magic-Cookie-1" as we have seen before and see what happens when performing a first ssh session:

With putty we see that the session already appears with a DISPLAY from 10, and that it has been created in the . Xauthority a line of the MIT-MAGIC-COOKIE-1 cookie for the display. The cookie value changes for each session. And without doing anything, when you run the xclock it runs and is displayed on the Windows 10 desktop, with two Xming icons appearing, one of the jmeter opened before and one of the xclock.

If we open other putty by connecting with the same user to the same server we will see what happens:

You can see that now the . Xauthority has 2 cookies, the previous session cookie and the new session cookie. and that runs the xclock equally smoothly, there are three Xmings.

These entries in . Xauthority can be managed with the xauth command with its add, remove, list, and other options.

Therefore with putty ssh it is not necessary to specify in Xming "No access control because it handles the authentication process well with MIT-MAGIC-COOKIE-1 cookie.

I hope I have clarified this topic of viewing remote applications with UI on-premises using X 11 forwarding, which usually gives problems. It should also be noted that in Windows in the user's .ssh folder there is a config file specifying ssh options for each host and different options that affect X 11 forwarding could be required for each case. I copy an example of this file in Windows 10:

Host mr56
  HostName mr56
  User adm01
  ForwardAgent yes

Host mr77
  HostName mr77
  User adm01
  ForwardAgent yes

Host cs12
  HostName cs12
  User adm02