ssh connection. X11 connection rejected because of wrong authentication
In trying to access a cluster in my lab by ssh and it work. but then I’m not able to do anything :
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3742445245774244524544">[email protected]</a>:~> nautilus X11 connection rejected because of wrong authentication. Could not parse arguments: Cannot open display
or
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="7f0a0c1a0d3f0a0c1a0d0c">[email protected]</a>:~> 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 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="7207011700324345405c43455c43425c4347">[email protected]</a>
EDIT 2 :
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="582d2b3d2a182d2b3d2a2b">[email protected]</a>:~> 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 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="df98809996939a919e929a809a919c909b969198e29fb3b0bcbeb3ba">[email protected]</a>,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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="8efbfdebfccefcebe3e1faeb">[email protected]</a>
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:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="384d4b5d4a784a5d55574c5d">[email protected]</a>> xauth nextract ~/xcookie $DISPLAY <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="26535543546654434b495243">[email protected]</a>> exit <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4633352334062a2925272a">[email protected]</a>> scp <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="85f0f6e0f7c5f7e0e8eaf1e0">[email protected]</a>:~/xcookie ~/xcookie <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="443137213604282b272528">[email protected]</a>> xauth nmerge ~/xcookie
And then verify that the cookie has been installed:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="82f7f1e7f0c2eeede1e3ee">[email protected]</a>> xauth list
Try out your X11 forwarding ssh connection.
~/.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.
Method 2
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:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="dcbaaeb9b89cb1bdbfb4b5b2b9b2bdb1b9">[email protected]</a> $ xhost access control disabled, clients can connect from any host SI:localuser:fred
but using
sudo I didn’t have access:<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3254405756725f53515a5b5c575c535f57">[email protected]</a> $ 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
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b0d6c2d5d4f0ddd1d3d8d9ded5ded1ddd5">[email protected]</a> $ 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:<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="1a7c687f7e5a777b797273747f747b777f">[email protected]</a> $ 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:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a7c1d5c2c3e7cac6c4cfcec9c2c9c6cac2">[email protected]</a> $ sudo su -
Add magic cookie value to Xauthority:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b0c2dfdfc4f0ddd1d3d8d9ded5ded1ddd5">[email protected]</a> # xauth add gcashvapp511u/unix:10 MIT-MAGIC-COOKIE-1 cdead42e9b4c159505c0c830deadbeef
Verify that it was added correctly:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="50223f3f24103d313338393e353e313d35">[email protected]</a> # cat ~/.Xauthority machinename10MIT-MAGIC-COOKIE-1���.�L���0[���[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="1664797962567b77757e7f787378777b73">[email protected]</a> ~]# export DISPLAY=localhost:10.0
Verify that it is working:
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="394b56564d7954585a5150575c5758545c">[email protected]</a> # 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.
Method 3
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.
The workaround is to simply do: export XAUTHORITY=$HOME/.Xauthority before running the remote X11 application.
- 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
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0
