ssh connection. X11 connection rejected because of wrong authentication

Question

In trying to access a cluster in my lab by ssh and it work. but then I'm not able to do anything :

user@users:~> nautilus
X11 connection rejected because of wrong authentication.
Could not parse arguments: Cannot open display

or

user@users:~> gedit
X11 connection rejected because of wrong authentication.

(gedit:151222): Gtk-WARNING **: cannot open display: localhost:11.0

It worked until today... and I don't know how to check if something had change. I don't have the root password for this machine, is there anything i can do ?

I have read lot of thing about this error such as this but nothing solved...

EDIT :

The local OS is Ubuntu 16 and the server is OpenSuse. I'm connecting this way :

ssh -XY -p22 [email protected]

EDIT 2 :

user@users:~> env
MODULE_VERSION_STACK=3.1.6
LESSKEY=/etc/lesskey.bin
NNTPSERVER=news
INFODIR=/usr/local/info:/usr/share/info:/usr/info
MANPATH=/usr/local/man:/usr/share/man
HOSTNAME=users
XKEYSYMDB=/usr/share/X11/XKeysymDB
HOST=users
TERM=xterm-256color
SHELL=/bin/bash
PROFILEREAD=true
HISTSIZE=1000
SSH_CLIENT=10.44.0.1 49729 22
MORE=-sl
SSH_TTY=/dev/pts/2
JRE_HOME=/usr/lib64/jvm/jre
USER=user
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LD_LIBRARY_PATH=/usr/local/cuda-5.5/lib:/usr/local/cuda-5.5/lib64:
XNLSPATH=/usr/share/X11/nls
ENV=/etc/bash.bashrc
HOSTTYPE=x86_64
FROM_HEADER=
MSM_PRODUCT=MSM
PAGER=less
CSHEDIT=emacs
XDG_CONFIG_DIRS=/etc/xdg
MINICOM=-c on
MODULE_VERSION=3.1.6
MAIL=/var/mail/user
PATH=/usr/local/cuda-5.5/bin:/home/user/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
CPU=x86_64
JAVA_BINDIR=/usr/lib64/jvm/jre/bin
INPUTRC=/home/user/.inputrc
PWD=/home/user
JAVA_HOME=/usr/lib64/jvm/jre
LANG=en_US.UTF-8
PYTHONSTARTUP=/etc/pythonstart
MODULEPATH=/usr/share/modules:/usr/share/modules/modulefiles
LOADEDMODULES=
QT_SYSTEM_DIR=/usr/share/desktop-data
SHLVL=1
HOME=/home/user
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
LS_OPTIONS=-N --color=tty -T 0
XCURSOR_THEME=DMZ
MSM_HOME=/usr/local/MegaRAID Storage Manager
WINDOWMANAGER=/usr/bin/gnome
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
LESS=-M -I
MACHTYPE=x86_64-suse-linux
LOGNAME=user
XDG_DATA_DIRS=/usr/share:/etc/opt/kde3/share:/opt/kde3/share
SSH_CONNECTION=172.17.10.15 22
MODULESHOME=/usr/share/modules
LESSOPEN=lessopen.sh %s
INFOPATH=/usr/local/info:/usr/share/info:/usr/info
DISPLAY=localhost:12.0
XAUTHLOCALHOSTNAME=users
LESSCLOSE=lessclose.sh %s %s
G_BROKEN_FILENAMES=1
JAVA_ROOT=/usr/lib64/jvm/jre
COLORTERM=1
_=/usr/bin/env

Answer 1

Xauthority Mini How To

On GNU/Linux systems running an X11 display server, the file ~/.Xauthority stores authentication cookies or cryptographic keys used to authorize connection to the display. In most cases, the authentication mechanism is a symmetric cookie which is referred to as a Magic Cookie. The same cookie is used by the server as well as the client.

Each X11 authentication cookie is under the control of the individual system authenticated user. Since the authetication cookie is stored as a plain text security token, the permissions on the ~/.Xauthority file should be rw for the owner only, 600 in octal format. However, the permissions on the authorization file are not enforced.

A user can list, export, create, or delete authentication cookies using the xauth program. The following command will create an authoratization cookie for DISPLAY 32.

xauth add localhost:32 - `mcookie`

Manual creation and manipulation of cookies is usually not needed when using X11 forwarding with ssh, because ssh starts an X11 proxy on the remote machine and automatically generates authorization cookies on the local display. However, for certain configurations the authorization cookie may need to be manually created and copied to the local machine.

This can be done in an ssh session and then use scp to copy the cookie.

ssh into remote machine:

ssh -XY user@remote

Check if an authorization cookie is present for the current X11 display

echo $DISPLAY
xauth list

If there's no environment variable named $DISPLAY then the X11 proxy did not start properly. It's important to note that DISPLAY 0 is typically locally logged in users and is only running if an xserver has been locally started via xinit. There is no requirement for a locally started X11 server in order for X11 forwarding to function through ssh.

If there's a $DISPLAY environment variable set but no corresponding authorization cookie for that display number, you can create one:

xauth add $DISPLAY - `mcookie`

And verify that there is now a cookie:

xauth list

You can copy that cookie and merge it into the local machine:

user@remote> xauth nextract ~/xcookie $DISPLAY
user@remote> exit
user@local> scp user@remote:~/xcookie ~/xcookie
user@local> xauth nmerge ~/xcookie

And then verify that the cookie has been installed:

user@local> xauth list

Try out your X11 forwarding ssh connection.

Notes on ~/.Xauthority

~/.Xauthority is a binary file which contains all the authorization information for each display the user may access. Each record is delimited by the two bytes 0x0100. Each field is preceeded by a hexidemical count of the field's number of bytes. All text is encoded in hexidecimal ASCII. The following table is the basic structure of the most common configuration of a MIT MAGIC COOKIE authorization:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 0100              0004        61616161           0002           3435                    0012          4d49542d4d414749432d434f4f4b49452d31   0010          c0bdd1c539be89a2090f1bbb6b414c2c 
----------------- ----------- ------------------ ------------  ----------------------  -------------  -------------------------------------- ------------ ---------------------------------------
 start-of-record   0xNumBytes  0xASCII Hostname   0xNumBytes     0xASCII Display Num     0xNumBytes    0xASCII Auth Type                      0xNumBytes    0xkey
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The top line is retrievable from the ~/.Xauthority file via the xauth nlist command. Of course, your authorization file will have different information from my example.

If the Security Extensions are in use with the X11 server, there are several configuration options for each authorization line including time limited authorization per cookie.

Answer 2

As explained here, I'd like to point out that similar symptoms now occur for a very different reason, to save people going down long xauth rabbit holes.

Anything installed with Snap wont work. So xeyes and xclock might work, but a new install of chromium-browser or firefox on Ubuntu wont. This is related to the fact that Snap sets HOME="$SNAP_USER_DATA" by default, which interferes with where X expects the Xauthority file to be.

The workaround is to simply do:

export XAUTHORITY=$HOME/.Xauthority

before running the remote X11 application.

---

Also, if you connected as a non-root user and try to run an application using su/sudo you might run in to the same error.

The reason is that

The xauth binary uses a combination of the $DISPLAY variable, and the [users] /home/.Xauthority file

Since this combination not match anymore to the current user you'll see this error.

---

• Ref 1: https://forum.snapcraft.io/t/x11-forwarding-using-ssh/2381
• Ref 2: https://forum.snapcraft.io/t/x11-connection-rejected-because-of-wrong-authentication/16528/3
• Ref 3: https://blog.lucid.net.au/2020/04/12/x11-forwarding-and-sudo/

Answer 3

I had this problem while trying to install software that really wanted to use a GUI (i.e. I couldn't figure out a way to install it without a GUI). My issue was that I was trying to run the executable with sudo and sudo had the wrong authentication.

Tip: Use xhost Command

The command xhost is useful because it tells you if your user has X11 connection access

In my case, my user had access:

fred@machinename $ xhost
access control disabled, clients can connect from any host
SI:localuser:fred

but using sudo I didn't have access:

fred@machinename $ sudo xhost
X11 connection rejected because of wrong authentication.
xhost:  unable to open display "localhost:10.0"

Once I figured this out, it explained why programs run with sudo would get the authentication error.

My Solution

To fix this I did the following:

Get value of $DISPLAY

fred@machinename $ echo $DISPLAY
localhost:10.0

Get the magic cookie value that matches the number from $DISPLAY, in my case this is the value of 10:

fred@machinename $ xauth list
machinename:4  MIT-MAGIC-COOKIE-1  e76c006944a28a5dbd3c54a0deadbeef
machinename/unix:4  MIT-MAGIC-COOKIE-1  e76c006944a28a5dbd3c54a0deadbeef
machinename/unix:10  MIT-MAGIC-COOKIE-1  cdead42e9b4c159505c0c830deadbeef

Change user to root:

fred@machinename $ sudo su -

Add magic cookie value to Xauthority:

root@machinename # xauth add gcashvapp511u/unix:10  MIT-MAGIC-COOKIE-1  cdead42e9b4c159505c0c830deadbeef

Verify that it was added correctly:

root@machinename # cat ~/.Xauthority 
machinename10MIT-MAGIC-COOKIE-1���.�L���0[���[root@machinename ~]# export DISPLAY=localhost:10.0

Verify that it is working:

root@machinename # xhost
access control disabled, clients can connect from any host
SI:localuser:fred

Then as root, I executed my program and it was finally able to run the GUI it so desperately wanted in order to install.