X11 Forwarding: X11 connection rejected because of wrong authentication. Error: cannot open display: localhost:10.0

Question

I've read numerous similar questions but many are outdated and nothing seems to work. I have an homePC <remotehome> and a laptop <locallaptop>, both running Ubuntu 22.04.

I'm away from home, I can ssh into <remotehome> both with psw or private key.

sudo ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa -X -p 2022 remoteuser@<remotehome>

(the port is 2022 because of port forwarding on my home router, idk if relevant)

Once on remote host, xdg-open or firefox commands give me:

X11 connection rejected because of wrong authentication.
Error: cannot open display: localhost:10.0

Running xlogo on remote terminal actually opens a window on my local desktop.

Useful Info:

df -H

on remote terminal, plenty of space.

ls -l ~/.Xauthority

output:

-rw------- 1 remoteuser remoteuser 69 mar 22 15:23 /home/remoteuser/.Xauthority

X11 Forwarding is enabled on <remotehome>

X11Forwarding yes

in /etc/ssh/sshd_config.

On client X11 Forwarding is enabled.

Host *
ForwardX11 yes

in /etc/ssh/ssh_config

xhost command gives the same output from both the remote and local terminal:

access control enabled, only authorized clients can connect
SI:localuser:<my-username-in-local-laptop>

The $XAUTHORITY var on my local desktop is:

/run/user/1000/.mutter-Xwaylandauth.PLS211

I've tried the solution proposed here and here and here. Nothing seems to work. Any help to debug this issue is really appreciated.

Answer 1

You should not need to use sudo with ssh: it is perfectly capable of forwarding the X11 connection as a regular user, no root powers needed.

Do you also have Firefox running on your local laptop?

By default, Firefox uses X11 window properties to detect if the same GUI session already includes a running instance of Firefox, and if it does, attempts to send it a command to open the URL given as a parameter (or a command to just open a new window if no URL) instead of starting a whole new session. The SSH forwarding makes Firefox on the remote desktop "think" the Firefox on the laptop is on the same host, but since this is not actually true, Firefox's attempt to send commands to the existing instance will fail.

If your goal is specifically to start a second instance of Firefox remotely on your home desktop, you'll need to tell it to not attempt to use this remote control feature. For example:

firefox --no-remote https://www.google.com

Note that a modern web browser like Firefox is very much designed to assume that its processes are running on the same host that contains the display - when this is not true, you will see that the remote Firefox's window updates very much slower than you've used to. Part of this comes from the delays caused by the added network communication between the X11 server and the Firefox process, and another part results from the fact that Firefox normally utilizes local GPU's acceleration features, which are not available when it's rendering to a display that's located in a different computer.

Instead of running a web browser remotely, it might be better to use SSH's dynamic port forwarding feature:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa -D 8080 -p 2022 remoteuser@<remotehome>

and then configure your web browser on your laptop to use a SOCKS proxy on localhost, port 8080:

(Remember the original proxy settings, you will need them later.)

Now, the Firefox on your laptop will connect the listening socket created by the SSH client, and all connections made through it will be forwarded to the sshd at the remote end of the SSH connection. Since sshd understands the SOCKS protocol, Firefox can now ask the remote sshd to make connections to any service.

And hey presto, you can browse as if your network connection was at the remote desktop, but your web browser runs fully locally, so window updates are quick and efficient!

When you end the SSH connection, the SSH client may appear to hang until you close the browser, as it might still be serving some SOCKS-forwarded TCP connections between the browser and the remote sshd.

After shutting down the SSH connection, remember to restore the browser's proxy settings back to original values, or else you may not be able to browse at all.