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?

7 Answers 7


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 *
ForwardX11 yes

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

ssh -X user@remote-host.com

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

Hope that helps.

  • 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, 2014 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, 2014 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, 2014 at 12:21
  • I issued "mesg n" what supresses wall-messages, but still kept getting those :(
    – Christian
    Oct 21, 2014 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, 2014 at 13:23

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


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

On local: xauth nmerge ~/xcookie

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

  • 4
    xauth add $DISPLAY - $(mcookie) did nothing for me. Sep 2, 2020 at 4:23
  • 2
    Works like a charm ❤️
    – 32r34wgf3e
    Mar 26, 2021 at 18:24

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

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

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.


Try to set this and it works for me:

X11UseLocalhost yes

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


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


Just run: unset DISPLAY before running aquatone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.