3

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.

atianalisi
  • 49
  • Is this answer related to the problem? – harrymc Mar 22 '23 at 15:10
  • I've tried disabling access control by running "xhost +" on the remote pc, problem still persists. – atianalisi Mar 22 '23 at 15:23
  • 1
    I was referring mostly to export DISPLAY='IP:0.0', where IP is the local workstation’s IP where you want the GUI application to be displayed. `. – harrymc Mar 22 '23 at 15:25
  • 2
    @SeñorCmasMas No, the fact that the DISPLAY variable on the remote host includes localhost means sshd is supplying a X11 proxy on the remote end, which tunnels the X11 protocol inside the SSH connection to the local workstation. If the DISPLAY had the IP address of the local workstation, that would mean the GUI apps on the remote host would attempt to use plain unencrypted X11 protocol to connect directly to the local workstation, which would be a massive security risk unless you are in a trusted network. – telcoM Mar 22 '23 at 15:38
  • 1
    @SeñorCmasMas Also, most Linux distributions have been configured to not accept incoming plain X11 connections since year 2000 at least. To make it work, you would have to explicitly configure the X11 server to listen for incoming TCP connections. – telcoM Mar 22 '23 at 15:41
  • I though so, the app should go through the ssh tunnel. I keep DISPLAY equal to localhost:10.0 – atianalisi Mar 22 '23 at 15:43
  • @telcoM , you really should answer this problem since you seem to know what it is. I clearly do not. Then I can learn from your answer too. – Señor CMasMas Mar 22 '23 at 16:06
  • @SeñorCmasMas The combination of SSH and X11 is a tricky subject, so writing an understandable answer took a while. Hope it helps! – telcoM Mar 22 '23 at 16:22

1 Answers1

2

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:

Firefox proxy settings dialog

(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.

telcoM
  • 4,392
  • I'm already capable to run firefox or anything through a ssh tunnel, it works but my question was about X11. Unfortunately the --no-remote flag didn't solve the issue. Upvoted because well crafted and informative. – atianalisi Mar 22 '23 at 19:48
  • Running a browser through an X11 connection tends to be abysmally slow - especially if the viewed web page is complex, as the browser tends to update the display repeatedly in a less-than-optimal manner. That's why I tried to give you an alternative that I've found works reasonably well. – telcoM Jul 13 '23 at 19:44