annoying message "X11 connection rejected because of wrong authentication" while there is no problem at all

Question

I'm having an annoying problem.

When I'm logged in to a specific host via SSH, the message

X11 connection rejected because of wrong authentication.

occurs three times seemingly random about once a minute. I have no idea where it comes from.

Actually, there is not even any slight problem with X11-forwarding, it works like a charm. But this message keeps appearing and it's driving me crazy.

Does anyone have an idea how to get rid of it?

I'm facing the problem no matter where I'm coming from, it happens from my Gnome-Desktop and also from a Windows-system using PuTTY, MobaXterm, Cygwin, whatever.

After twiddling some more I found the cause to be a monitoring-agent (check_mk). This checks some runtime-parameters of running tasks, the message appeared every time, when this agent was triggered from the monitoring-system, exactly when PostgreSQL-status is checked. It seems this process tries to open an X11-connection but fails. The message is then spit over into my terminal-session as it tried to use my forwarded X11-session.

Is there a way to disable this message at all?

Also see [*"su" with error "X11 connection rejected because of wrong authentication"*](https://unix.stackexchange.com/q/110558/20230) — Abdull, Aug 22 '23 at 14:42

score 35 · Answer 1 · edited Aug 22 '23 at 16:19

35

Make sure you are not running out of disk space

Run df and make sure you have sufficient disk space, if you are low on disk space remove unnecessary files from your system:

$ df -h

If there are quotas imposed on the file systems, check that you did not exceed your quota:

$ quota -s

Make sure ~/.Xauthority owned by you

Run following command to find ownweship:

$ ls -l ~/.Xauthority

Run chown and chmod to fix permission problems [replace user:group with your actual username and groupname]:

$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority

Make sure X11 SSHD Forwarding Enabled

Make sure following line exists in sshd_config file:

$ grep X11Forwarding /etc/ssh/sshd_config

Sample output:

X11Forwarding yes

If X11 disabled add following line to sshd_cofing and restart ssh server:

X11Forwarding yes

Make sure X11 client forwarding enabled

Make sure your local ssh_config has following lines:

Host remote-host.com
    ForwardX11 yes

Finally, login to remote server and run X11 as follows from your Mac OS X or Linux desktop system:

ssh [email protected]

Credit for information belongs here: http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong-authentication/

Hope that helps.

edited Aug 22 '23 at 16:19

Community

1

answered Oct 19 '14 at 13:47

devnull

5,331
21
36

I read that, but as there is actually no problem starting X11-applications those steps were not appliable. However, in the meantime I found the cause of the problem and will update now. – Christian Oct 19 '14 at 13:49
As mentioned, this is not relevant in this case. The problem is not that my attempt to forward an X11-connection fails. The problem is that another user tries to use my X11-Forwarding and that the message is spit over to my active terminal session what I don't want. The question is "Is there a way to disable this message at all?". – Christian Oct 21 '14 at 11:28
I updated my answer for a user that asked for it then removed his comment after. For your question try disabling wall access to all but root(assuming that process isn't being run by user root):$ sudo chmod g-s /usr/bin/wall $ echo foo | wall – devnull Oct 21 '14 at 12:21
I issued "mesg n" what supresses wall-messages, but still kept getting those :( – Christian Oct 21 '14 at 12:50
If that process is executed by root then you would. Root can't be surpressed. If that is the case, create a 'monitor' or whatever user and move the monitoring and such to be executed by that user and then you won't see those messages anymore because it won't be from root. – devnull Oct 21 '14 at 13:23
Good stuff. Adding ForwardX11 yes to ssh_config was the missing step for me. Thank you. – Hexatonic Feb 05 '16 at 01:54
WHICH COMPUTER?? - There's two computers involved here, and it doesn't do much good to tell me to edit files and check settings if you don't mention which of the computers I'm supposed to be doing this on. – R.M. May 21 '17 at 16:33
http://wiki.docking.org/index.php/How_to_access_X11_Forwarding_after_becoming_root – Alex Punnen Aug 13 '20 at 09:56
I really hate this error message. xeyes works just fine but trying to get something more complicated to run just prints out this error message with no plain fixing guide. – Antti Rytsölä Mar 25 '23 at 15:25

score 11 · Answer 2 · answered Apr 10 '23 at 09:08

11

I had interesting version, xeyes and xlogo works but chromium doesn't.

It was a feature from using snap to install chromium.

Quick fix:

export XAUTHORITY=$HOME/.Xauthority 
chromium

See more:

https://unix.stackexchange.com/a/709789/12207

answered Apr 10 '23 at 09:08

Antti Rytsölä

287
3
5

You know when you've hit something when the google results show your own answer time after time. – Antti Rytsölä Aug 31 '23 at 18:09

g__c · Answer 3 · 2020-05-18T13:26:58.513

8

I had the very same issue and this works for me. (Note: this is not my solution, but since I strived to find it I repost it here. You can find the original here and here)

1. Log onto remote server

echo $DISPLAY This should display your current X11 display

xauth list If nothing prints on console, it means ssh did not automatically generate the X11 authorization cookies on the local display properly

2. Add the authorization cookie

xauth add $DISPLAY - `mcookie` This adds your display's authorization cookie to the xauth

xauth list Check whether your display is added

3. Merge your cookie with your local machine

xauth nextract ~/xcookie $DISPLAY

exit

On local: scp user@remote:~/xcookie ~/xcookie

On local: xauth nmerge ~/xcookie

Finally log again in the remote server and it should be resolved.

edited May 18 '20 at 13:26

answered May 18 '20 at 13:21

g__c

81
1
2

5

`xauth add $DISPLAY - $(mcookie)` did nothing for me. – Sridhar Sarnobat Sep 02 '20 at 04:23
2

Works like a charm ❤️ – 32r34wgf3e Mar 26 '21 at 18:24
1

This worked, after also doing this: `export XAUTHORITY=$HOME/.Xauthority` – Bram Apr 21 '23 at 16:45

score 4 · Answer 4 · answered Oct 19 '14 at 13:24

4

It could be untrusted X11 forwarding timeout. Using the ForwardX11Timeout option with a large timeout may help, as suggested in https://bugzilla.mindrot.org/show_bug.cgi?id=1718 (I got this problem in the past, but IIRC, it disappeared after some upgrade).

answered Oct 19 '14 at 13:24

vinc17

11,912
38
45

Unfortunately not, also when I explicitly set `ForwardX11Trusted yes` in `/etc/ssh_config`. – Christian Oct 19 '14 at 13:34

score 3 · Answer 5 · edited Aug 29 '22 at 15:12

If you have SELINUX enforcing, and your home directory is not under the /home directory, that is your problem. Targeted SELINUX settings assume all user home directories are under /home, so xauth doesn't work correctly because the SELINUX type on your home directory is not correct. I wish I could recommend a fix, but the one I found did not work. I set SELINUX to permissive to get around this problem. Better would be set correct label like:

semanage fcontext -a -e /home <custom_path>
restorecon -R -v <custom_path>

score 1 · Answer 6 · answered Sep 04 '18 at 21:12

1

Try to set this and it works for me:

X11UseLocalhost yes

reference: https://medium.com/@toja/using-x11-apps-in-mac-os-x-c74b304fd128

answered Sep 04 '18 at 21:12

Andong Zhan

111
2

score 0 · Answer 7 · answered Oct 11 '18 at 20:59

Install XQuartz on mac if required and login directly with the user. Example - While installing oracledb I was trying to login with root and then running the command from oracle user after sudo su - oracle.

Login directly with oracle ssh -X oracle@hostname

score 0 · Answer 8 · edited Jun 09 '20 at 23:26

0

Just run: unset DISPLAY before running aquatone.

edited Jun 09 '20 at 23:26

Jeff Schaller

66,199
35
114
250

answered Jun 09 '20 at 21:24

user417089

1

score 0 · Answer 9 · answered Aug 22 '22 at 19:13

0

I had this issue, and it was due to a read only file system.

answered Aug 22 '22 at 19:13

philn

121
4

score 0 · Answer 10 · answered Mar 18 '23 at 02:36

Adding this answer because none of the other answers here worked, and all seem to highlight unnecessary trouble-shooting steps that will likely mess up your configuration even more. (Another reason for leaving this answer is for my own purposes so I can come back to it when needed.)

If you attach to a tmux session while in a ssh session and the display doesn't work, it will likely require 2 steps to fix (per terminal.)

Step 0

Ensure you can actually open X11 applications and forward them to your local machine through ssh. This is usually easiest by running a X11 program lightweight is better.) If not make sure you connect with ssh -Y or ssh -X with either the X or Y switch, with forwarding enabled in client/server configs. If this fails you simply won't be able to get anything working.

Step 1

Connect to your tmux session, then within the terminal fix your display variable:

export DISPLAY="`tmux show-env | sed -n 's/^DISPLAY=//p'`"

will fix the display variable. Try launching an X11 app at this point and you might have the error

X11 connection rejected because of wrong authentication.

Step 2

If you have the error above, detach tmux so that you are back in the orignal terminal with working display. Then run

xauth list
HOSTNAME/unix:10  MIT-MAGIC-COOKIE-1  1ab9b57e04236de28b161dd0add5ce59

Copy this string, attach tmux then add this string using

xauth add HOSTNAME/unix:10  MIT-MAGIC-COOKIE-1  1ab9b57e04236de28b161dd0add5ce59

The string must be copied exactly, without errors. Once this command runs X11 applications should work.