X11 Forwarding using SSH


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…

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.

I just tried this by doing:

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

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.


I believe @jdstrand beat me to it

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?

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.


Ok, thanks for getting back to me!

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.

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.

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

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

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.


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

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.

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:

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 for a better way IMHO.

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