X11 connection rejected because of wrong authentication

I am trying to re-create functionality I’ve had for years; namely, installing an app, GIMP, on a remote server and running it remotely and seeing the graphical output locally, over ssh -X.

$ snap version
snap    2.44.1
snapd   2.44.1
series  16
ubuntu  18.04
kernel  5.3.0-46-generic

Before posting this I have, on the remote machine:

  • verified that /root is real (not a symlink, nor a bind to another directory)
    (Note: I have to reveal this because of an earlier install issue I posted)
  • “started fresh” in the sense I:
  • removed the snap: sudo snap remove purge gimp
  • removed snap itself: apt remove snap/apt purge snap
  • reinstalled snap: sudo apt install snap
  • reinstalled gimp’s snap: sudo snap install gimp

Then I logged in the customary way.
% ssh -X remotehost

Note that other graphical apps work:
% xeyes
% qgis

[both work, meaning output visible on localhost]

But not:
% gimp
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8)
X11 connection rejected because of wrong authentication.
Cannot open display:

However, the DISPLAY variable has been set (presumably by ssh, to send it back to the logging-in host):
$ env|grep DISPLAY

What more may I check?

Thank you.
[Incidentally, I have edited this post a few times trying to get the remaining cmdlines and responses to be “Preformatted Text” but the editor is ignoring the codes in the Preview while showing them in the Composer.]

1 Like

I think you’ve found a deficiency in the X11 interface :slight_smile: This is a bug that should be fixed in snapd. @jdstrand, I think this one is for you. The current X11 interface probably doesn’t account for remote X11 sockets.

1 Like

I found and followed this, rebooted and got the same result:

But don’t need to go there, here’s the conclusion which is what I implemented (exc. in /etc/ssh/sshd_config because /etc/opt/ssh doesn’t exist in my Ubuntu 18.04 install):

Oracle (internal) support came back with a fix that worked 
  "set X11UseLocalhost variable to 'no' in the file /etc/opt/ssh/sshd_config"
Probably SSHD daemon needs to be restarted.

I added the line: “X11UseLocalhost no” to /etc/ssh/sshd_config and rebooted to restart sshd although if you’re watching, you could do this with

% sudo service ssh restart
% /etc/init.d/ssh restart


Any update on this? I just upgraded my Ubuntu server, and have completely lost the ability to test our code. I need to get chromedriver working in due course, but even running the chromium-browser is not possible with the snap. LIke @DavidOertl, I’ve followed the various guides on ensuring SSH Forwarding is working, and all other apps are fine.

I know this is Open Source and all, but I’m completely dead in the water so help really appreciated.

Thanks, Shaheed

P.S. I had previously held off using the snap until I got my $HOME-is-not-under-home, but I have the needed bind mount in place now. Pending that, I was able to replace the snap with pre-snap chromium-xxx, but that is now broken with some seemingly hard-coded snap dependency; if there is a way to revert that would get me going, I’d appreciate that too.

Of course, immediately after posting, I found X11 Forwarding using SSH, and with that, authentication is working, but now I get an actual crash:

$ chromium-browser
[424559:424732:0522/070735.105951:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.ListActivatableNames: object_path= /org/freedesktop/DBus: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.110" (uid=1001 pid=424559 comm="/snap/chromium/1143/usr/lib/chromium-browser chrom" label=“snap.chromium.chromium (enforce)”) interface=“org.freedesktop.DBus” member=“ListActivatableNames” error name="(unset)" requested_reply=“0” destination=“org.freedesktop.DBus” (bus)
[424559:424559:0522/070735.263224:ERROR:browser_switcher_service.cc(238)] XXX Init()
[424728:424728:0522/070735.279903:ERROR:viz_main_impl.cc(159)] Exiting GPU process due to errors during initialization
[424767:7:0522/070735.388381:ERROR:command_buffer_proxy_impl.cc(125)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
…/…/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0063
[424559:424715:0522/070736.790303:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn’t usable. Goodbye.
Trace/breakpoint trap (core dumped)

I presume I need to take this up with the chromium folk? (The remote host here is a headless server).

Thanks, Shaheed

1 Like

Yes, assuming this is on amd64, the syscall in question is ‘uname’ and their seccomp sandbox needs to be updated to allow it, or the thing that is calling uname should not do that.

That said, what is the apparmor denial from journalctl that corresponds to that AccessDenied dbus failure? It is possible that it is the denial that is triggering error handling code (which calls uname).

Thanks, but after a good deal of scratching around, it seems that over time, this is/has been a known problem for chromium. There are reports of issues like this going back (on-and-off) for years…

This is being tracked by bug #1903957.