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:
What works:
.Xauthority
file to the other user and X11 forwarding works as well.Some setup info:
DISPLAY
variable is set in container (to host-ip-addr:10.0 because of TCP port 6010 where sshd is listening).tcpdump
checked).What does not work:
X11 connection rejected because of wrong authentication.
xterm: Xt error: Can't open display: host-ip-addr:10.0
Things i tried:
ssh -Y
option on machine B"X11ForwardTrusted yes"
in ssh_config on machine Bxhost +
(so allow any clients to connect) on machine BHost *
in ssh_config on machine BX11UseLocalhost no
in sshd_config on machine A (to allow non-localhost clients)xauth add
from the login user on machine A.Xauthority
file from a working user into the container.Xauthority
file has correct permissions and ownerHow 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.
Thanks so much @Lazarus535
I found that for me adding the following to my docker command worked:--volume="$HOME/.Xauthority:/root/.Xauthority:rw"
I found this trick here
EDIT:
As Lazarus pointed out correctly you also have to set the --net=host
option to make this work.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With