X11 forwarding of a GUI app running in docker

First off: I have read the answers to similar questions on SO, but none of them worked.

IMPORTANT NOTE: The answer below is still valid, but maybe jump to the end for an alternative.

The situation:

• App with GUI is running in a docker container (CentOS 7.1) under Arch Linux. (machine A)
• Machine A has a monitor connected to it.
• I want to access this GUI via X11 forwarding on my Arch Linux client machine. (machine B)

What works:

• GUI works locally on machine A (with /tmp/.X11-unix being mounted in the Docker container).
• X11 forwarding of any app running outside of docker (X11 forwarding is set up and running properly for non-docker usage).
• I can even switch the user while remotely logged in, copy the .Xauthority file to the other user and X11 forwarding works as well.

Some setup info:

• Docker networking is 'bridged'.
• Container can reach host (firewall is open).
• DISPLAY variable is set in container (to host-ip-addr:10.0 because of TCP port 6010 where sshd is listening).
• Packets to X forward port (6010) are reaching the host from the container (tcpdump checked).

What does not work:

• X11 forwarding of the Docker app
• Errors:

X11 connection rejected because of wrong authentication.

xterm: Xt error: Can't open display: host-ip-addr:10.0

Things i tried:

• starting client ssh with ssh -Y option on machine B
• putting "X11ForwardTrusted yes" in ssh_config on machine B
• xhost + (so allow any clients to connect) on machine B
• putting Host * in ssh_config on machine B
• putting X11UseLocalhost no in sshd_config on machine A (to allow non-localhost clients)
• Adding the X auth token in the container with xauth add from the login user on machine A
• Just copying over the .Xauthority file from a working user into the container
• Making shure .Xauthority file has correct permissions and owner

How can i just disable all the X security stuff and get this working?

Or even better: How can i get it working with security?

Is there at least a way to enable extensive debugging to see where exactly the problem is?

Alternative: The first answer below shows how to effectively resolve this issue. However: I would recommend you to look into a different approach all together, namely VNC. I personally switched to a tigerVNC setup that replaces the X11 forwarding and have not looked back. The performance is just leagues above what X11 forwarding delivered for me. There might be some instances where you cannot use VNC for whatever reason, but i would try it first.

The general setup is now as follows: -VNC server runs on machine A on the host (not inside a docker container). -Now you just have to figure out how to get a GUI for inside a docker container (which is a much more trivial undertaking). -If the docker container was started NOT from the VNC environment, the DISPLAY variable maybe needs ajdusting.

Ok, here is the thing:

1) Log in to remote machine

2) Check which display was set with echo $DISPLAY

3) Run xauth list

4) Copy the line corresponding to your DISPLAY

5) Enter your docker container

6) xauth add <the line you copied>*

7) Set DISPLAY with export DISPLAY=<ip-to-host>:<no-of-display>

*so far so good right?

This was nothing new...however here is the twist: The line printed by xauth list for the login user looks something like this (in my case):

<hostname-of-machine>/unix:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

Because i use the bridged docker setup, the X forwarding port is not listening locally, because the sshd is not running in the container. Change the line above to:

<ip-of-host>:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

In essence: Remove the /unix part.

<ip-of-host> is the IP address where the sshd is running.

Set the DISPLAY variable as above.

So the error was that the DISPLAY name in the environment variable was not the "same" as the entry in the xauth list / .Xauthority file and the client could therefor not authenticate properly.

I switched back to an untrusted X11 forwarding setting.

The X11UseLocalhost no setting in the sshd_config file however is important, because the incomming connection will come from a "different" machine (the docker container).