X11 Forwarding using SSH

snapd
1

Hey,

Are there some plans going on to make it possible to forward snaps using ssh? I have tried to forward a few snaps, but unfortunately they mostly default to their CLI interface, and some refuse to start at all…

1 Like
2

We’ll need some more details about what is not working. There’s no real reason why the forwarding shouldn’t happen, and we would definitely like to see it fixed once we learn why it’s not working.

3

I just tried this by doing:

$ ssh -X localhost
$ xterm # it launches
xterm$ exit
$ brave
X11 connection rejected because of wrong authentication.
[1]

I then strace’d brave and saw it was trying to access $SNAP_USER_DATA/.Xauthority, which of course did not exist. I then ran: $ ln -s ~/.Xauthority ~/snap/brave/current/.Xauthority, tried again and it worked.

7 Likes
4

I believe @jdstrand beat me to it

5

So… Can we call this a confirmed issue then?

I found another thread, and asked in there as well: https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116/11

Perhaps it is related?

6

This issue is definitely confirmed. What remains is a design and someone to implement the design. This is a different issue than the other topic you mentioned.

2 Likes
7

Ok, thanks for getting back to me!

8

FWIW exporting XAUTHORITY=$HOME/.Xauthority makes this work as well, so maybe there is something to be done in that regard. Obviously wouldn’t work if the snap in question is not connected to the home interface.

3 Likes
9

the home interface does not allow access to hidden files so i doubt it has any influence here … also note that HOME=“$SNAP_USER_DATA” by default.

11

Right, so it’s probably the x11 interface that allows access to .Xauthority.

Also, by $HOME I mean the host $HOME.

12

The x11 interface uses the X apparmor abstraction which has owner @{HOME}/.Xauthority r,. This is why the symlink trick I mentioned in X11 Forwarding using SSH works.

If this were to be fixed, exporting the environment variable is way nicer than creating a symlink. Perhaps snapd could export XAUTHORITY=<real home>/.Xauthority if the x11 interface is connected. I’m pretty sure different distros will set this to other values, so there might be distro-specific code. A good first pass might be to check if XAUTHORITY is already set, and if so, use it otherwise export the one in the user’s real home.

2 Likes
13

It’s been a while - have there been any progress made to address this issue?

14

No, it hasn’t been prioritized high since a workaround exists (eg, just set XAUTHORITY in the environment before running the snap. The snap could even do this itself).

The desktop part could in theory do this, but it would have to be careful since all distros may not use the same path to the Xauthority file.

15

I probably face a similar issue Access X11 in a background service and creating the symlink does fix the issue for me but that’s one extra step and not something I expect the users of snap to be excited about :slight_smile:

16

The snap can do it itself with: ln -s $(getent passwd $USER|cut -d ':' -f 6)/.Xauthority $HOME/.Xauthority. The desktop helper could to, but see X11 Forwarding using SSH - #11 by Saviq for a better way IMHO.

1 Like
17

Turns out the snap install version of freecad (v0.18) is also looking for .Xauthority in all the wrong places when I try to run it remotely via

% ssh -X

The woggling thing is that virtually all other X-apps work, with the exception of ‘brave’ which I downloaded solely to confirm that it too (still) doesn’t have an .Xauthority fix.

For FreeCAD, taking jdstrand’s advice (thank you),

% ln -s ~/.Xauthority ~/snap/freecad/current/.Xauthority

turned “X11 connection rejected because of wrong authentication.” into Success.

IMHO “Wrong authentication” is gobbledy-gook-speak for “Can’t find an .Xauthority file.”

3 Likes
18

so i ran into this. i can confirm that just exporting XAUTHORITY=$HOME/.Xauthority does indeed help when ssh’ed into a remote machine, but it makes it more difficult to run with the syntax of ssh -YC remote@machine application
creating a symlink does resolve it for that usecase so that approach seems to work better.

interesting enough when I echo XAUTHORITY is set so perhaps we could at least make snap use that variable? can i assume this would be need to be done in snapd?

19

Thank you @jdstrand for your solution.

This reply is to inform whoever is in charge that this issue continues to exist and has cost me a lot of time until I found this thread.

Here is the situation:

  • running a remote VM with:
    • Ubuntu 20.04.3 LTS
    • Xfce
  • accessing it from a Windows 10 client via RDP
  • default chromium install via snap
    ( XAUTHORITY had already been set before chromium installation)
  • starting from command line just yielded this message:
    “No protocol specified … ERROR:browser_main_loop.cc(…)] Unable to open X display.”
    (while a browser like firefox (without snap) was working fine after installation)

@jdstrand’s sym-link solution solved the issue and I wonder why this continues to exist after such a long time and causing so much pain…

20

I just spent a few hours tracking this down again, as Jammy made snap the supported way to run firefox, but apparently this still isn’t fixed. Is there something pending? Can I bump up the priority just based on likely numbers of users affected?

See also https://www.technomancer.com/archives/616

21

well, you could try to create a firefox bug instead of commenting on an old, unrelated snapd thread :wink:

… that is usually a good way to make the actual maintainers aware …