51

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?

Improve this question
1

10 Answers 10

Reset to default
56

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

Improve this answer
6
  • 4
    You know when you've hit something when the google results show your own answer time after time.
    – Antti Rytsölä
    Commented Aug 31, 2023 at 18:09
  • I've had this working for a few days -- every time I reconnected via SSH I had to re-run this, but then it worked -- but it suddently stopped working, without me changing anything about the set-up or installed packages. I've no idea what could've changed.
    – alelom
    Commented May 19, 2024 at 6:27
  • @alelom Well you sort of have to run it every time you log in. To automate, run echo "export XAUTHORITY=$HOME/.Xauthority" >> ~/.bashrc , or use a browser not installed from snap.
    – Antti Rytsölä
    Commented May 20, 2024 at 7:13
  • I know, I run it at every reconnection (should've said log-in perhaps), as I stated it in my comment above. It still stopped working.
    – alelom
    Commented May 20, 2024 at 7:20
  • 1
    This also works for Thunderbird SNAP from Ubuntu 24.04.1 LTS
    – Chester Gillon
    Commented Oct 6, 2024 at 13:15
37

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.

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

Improve this answer
4
  • 5
    xauth add $DISPLAY - $(mcookie) did nothing for me.
    – Sridhar Sarnobat
    Commented Sep 2, 2020 at 4:23
  • 2
    Works like a charm ❤️
    – 32r34wgf3e
    Commented Mar 26, 2021 at 18:24
  • 2
    This worked, after also doing this: export XAUTHORITY=$HOME/.Xauthority
    – Bram
    Commented Apr 21, 2023 at 16:45
  • Confirmed as a working solution with an additional step: export XAUTHORITY=$HOME/.Xauthority
    – Slavkó Medvediev
    Commented May 7, 2024 at 11:02
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).

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

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>
Improve this answer
3

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.

Improve this answer
2
  • In Step 1, you can simply do eval $(tmux show-environment -s) instead.
    – Kenyon
    Commented Nov 22, 2023 at 21:43
  • Thanks! This is the correct answer.
    – geek2000
    Commented Dec 3, 2023 at 1:48
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

Improve this answer
0

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

Improve this answer
0

Just run: unset DISPLAY before running aquatone.

Improve this answer
0

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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .