Usually I do this on ssh for getting a X application using sudo su

ssh -X server

OKI login

xauth list $DISPLAY

which returns to me

server/unix:10  MIT-MAGIC-COOKIE-1  blablablablabla

Then I do

sudo su
xauth add server/unix:10  MIT-MAGIC-COOKIE-1  blablablablabla

And after running an X application..I get it, it is correct.

The problem is on Centos7, I do

xauth list $DISPLAY

And it returns nothing. I try to add MIT magic cookies given by

xauth list

But of course it doesn't work. The normal X-forwarding via ssh, without sudo works.

The settings of sshd are the same on 3 servers:

  1. slackware WORKS
  2. hpux WORKS
  3. centos7 NOT WORKING
  • I try of course with selinux disabled,nothing to do
    – elbarna
    Nov 7, 2015 at 0:17

7 Answers 7


Another solution is to merge the .Xauthority file of the current user with that of the root user.

  1. ssh user@host
  2. change the .Xauthority file permissions so that root also has access to it.
  3. sudo su - root
  4. xauth merge /home/users/user/.Xauthority


gedit somefile.log

It should open a gedit window.


to make the solution permanent you can modify the .bashrc file of the login user adding

if [ -z "$XAUTHORITY" ]; then
    export XAUTHORITY=$HOME/.Xauthority

moreover you have to update your sudoers file adding the row

Defaults env_keep+="DISPLAY XAUTHORITY"

if root has read permissions on the login user's .Xauthority file you'll be able to use X applications.


Solution found. An alternative method copied from this blog Using this script



    su - $userfirst -c 'xauth list' |\
         grep `echo $DISPLAY |\
             cut -d ':' -f 2 |\
             cut -d '.' -f 1 |\
             sed -e s/^/:/`  |\
         xargs -n 3 xauth add

Or simply Logging as user1

xauth list

su or sudo su user2


This might be an old post, but I solved this permanently linking (in server) my sudoer user .Xauthority file with the root one:

sudo ln -s /home/userWithPrivileges/.Xauthority /root/.Xauthority

This way I don't have to do anything else ever, I can now launch any GUI app with or without sudo.


A very simple generic command:

sudo xauth merge /home/$USER/.Xauthority

This activates the root environment and merges the xauth info of the current (non root) user.

Another alternative, should prevent ownership problem reported in the comments on Slackware:

cat ~/.Xauthority | sudo xauth merge -
  • I tried this command and work, but has a little bad thing, the permissions of Xauthority files of user become of root. ls -lhd /home/user/.Xauthority -rw------- 1 root root 318 2021-07-21 20:34 /home/user/.Xauthority
    – elbarna
    Jul 21, 2021 at 18:35
  • 1
    Just checked on Ubuntu 20.04. The ownership of the /home/$User/.Xautority is not modified. The 'xauth merge ' is executed in the root environments and the file that is changed is /root/.Xauthority - as expected. Maybe this behaves differently on other systems, but I could not recreate the problem on ubuntu 20.04.
    – QT-1
    Jul 22, 2021 at 14:25
  • I confirm the problem on Slackware current ls -lhd .Xauthority -rw------- 1 myuser myuser 63 2021-07-21 21:46 .Xauthority sudo xauth merge /home/$USER/.Xauthority ls -lhd .Xauthority -rw------- 1 root root 63 2021-07-22 21:50 .Xauthority
    – elbarna
    Jul 22, 2021 at 19:51
  • 1
    Please check the alternative above that passes .Xauthorith via stdin. Should prevent ownership changes.
    – QT-1
    Jul 26, 2021 at 10:39
  • It fails $ cat ~/.Xauthority | sudo xauth merge - $ xmms No protocol specified ** CRITICAL **: Unable to open display $ ls -lhd .Xauthority -rw------- 1 root root 255 2021-07-27 01:04 .Xauthority
    – elbarna
    Jul 26, 2021 at 23:05

The following allows any user to run X11 applications as root.

Run the following as the root user:

echo '\cp /home/$(logname)/.Xauthority Xauthority-tmp && xauth add $(xauth -f Xauthority-tmp list | tail -1)' >> /root/.bash_profile
echo 'rm -f Xauthority-tmp' >> /root/.bash_profile 

Now you should be able to sudo su - from any user and start X11 applications.

Tested on Centos 8 (things like the default home dir may need to be adjusted and I believe $(logname) is not portable, but hopefully this helps someone!)

  • Could you elaborate a little more what this does exactly, and what the security implications of using this are? Aug 17, 2020 at 9:24

If you want to automate this, then !

1- Add to your login user ~/.bashrc file the following :

xauth list |grep `uname -n` > /home/$(whoami)/.auth
echo $DISPLAY > /home/$(whoami)/.display

2- Add to the root user /root/.bashrc file the following :

xauth add $(cat /home/$loguser/.auth) 
export DISPLAY=$(cat /home/$loguser/.display)

Then when executing su - root the cookie and DISPLAY variable are loaded automatically.

You must log in to answer this question.

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