71

As root, I'm connecting to a remote host to execute a command. Only "standarduser" has the appropriate id-file and correct .ssh/config, so I'm switching the user first:

su standarduser -c 'ssh -x remotehost ./remotecommand'

The command works fine, but despite the fact that I used "-x" (disable X11-Forwarding) and having X11Forwards disabled in /etc/ssh/ssh_config, I still get the error message:

X11 connection rejected because of wrong authentication.

I'm not getting the error message when I'm logged in as "standarduser".

This is quite annoying as I would like to integrate the command in a cron job file. I understand that the error message refers to the wrong authentication of root's .XAuth file, but I'm not even trying to connect via X11.

Why is "ssh -x" not disabling the X11 connection and throwing the error message?

UPDATE: The message only shows when I'm logged in within a screen, when using the command stated above on the local machine itself (without screen), I don't get an error message, so this should be fine with cron, too.

I also started the same command with -v and surprisingly got the error message FIRST, even before the status information from SSH:

root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

This led me to the problem itself, it is NOT the ssh which is throwing the error message, it's su:

root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi

Why do I only get this error within screen? How can I disable this error message?

Neurotransmitter
  • 2,883
  • 2
  • 19
  • 30
Stefan M
  • 1,606
  • 1
  • 12
  • 20
  • 1
    Run the command again and add `-v` to the ssh options, then paste the output into your question. – Jenny D Jan 23 '14 at 09:50

9 Answers9

105

Seems like your root lacks some X11 magic cookie in the .Xauthority, which your standarduser has. Here is how to fix this.

SHORT VERSION (thanks to @Vladimir Panteleev)

standarduser@localhost:~$ sudo xauth add $(xauth list | grep "unix$(echo $DISPLAY | cut -c10-12)")

ORIGINAL LONG VERSION

To fix things, first detect which display number standarduser uses:

standarduser@localhost:~$ echo $DISPLAY
localhost:21.0

In this case it is 21.0. Secondly, display standarduser's list of cookies:

standarduser@localhost:~$ xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  51a3801fd7776704575752f09015c61d
localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22  MIT-MAGIC-COOKIE-1  22ba6595c270f20f6315c53e27958dfe
localhost/unix:20  MIT-MAGIC-COOKIE-1  267f68b51726a8a381cfc10c91783a13

The cookie for the 21.0 display is the second in the list and ends with 104f.

The last thing to do is to add this particular cookie to the root's .Xauthority. Log in as root and do the following:

root@localhost:~$ xauth add localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f

This is how you can mitigate the X11 connection rejected because of wrong authentication error when you run su as a different user in Bash script or screen.

Thanks to this guy for inspiration.

Neurotransmitter
  • 2,883
  • 2
  • 19
  • 30
  • Interesting. I tried that, but that didn't work for me either. In my particular case, I can launch almost anything (another xterm, VirtualBox), but I cannot launch gedit (I get the same error). However, if I change to root, then I can launch gedit. I followed the instructions to the letter but nothing. Something else must be amiss. – luis.espinal Jun 26 '14 at 13:16
  • @luis.espinal hope someone suggest a solution to your particular problem. – Neurotransmitter Jun 30 '14 at 21:33
  • 2
    Works great! I shortened it a little: 1. ``xauth list|grep unix`echo $DISPLAY|cut -c10-12` > /tmp/xauth`` 2. `sudo...` 3. ``xauth add `cat /tmp/xauth` `` – bmaupin Jun 29 '15 at 19:44
  • 2
    The long version worked like a charm, but the short version errored on centos with "xauth: (argv):1: bad "add" command line" – Sam Aug 20 '15 at 23:16
  • 1
    short version worked for me on centos 7 – tdc Oct 13 '15 at 20:19
  • The possible reason why short version may not work is a copy-paste procedure. Check if the backticks are copied properly and not get replaced by the quotes characters. This is crucial. – Neurotransmitter Oct 14 '15 at 14:36
  • CentOS seems to take its own red-hattian approach for a lot of things. It's not a surprise that things don't all work the same way. – William T Froggard Nov 12 '15 at 04:40
  • 1
    worked like magic) – Alex Feb 17 '17 at 16:41
  • 1
    on Ubuntu 18.04.1 short version works fine. – Panagiotis Simakis Sep 12 '18 at 13:40
  • 1
    You can avoid writing to a file like this: `sudo sh -c "xauth add $(xauth list | grep unix$(echo $DISPLAY | cut -c10-12)) && xterm-or-whatever..."` Of course, [@Juan's answer](https://unix.stackexchange.com/a/162675/432450) is simpler – Dave Abrahams Sep 11 '20 at 18:03
  • @DaveAbrahams now it feels like a "longest copy-pasteable command" game, which doesn't help understanding the underlying issue. – Neurotransmitter Sep 12 '20 at 20:14
  • @Neurotransmitter true, but isn't there something to be said, from a security POV, for not writing auth info into a file? – Dave Abrahams Sep 28 '20 at 14:44
  • @DaveAbrahams true, it's better not to save this stuff to a file. Although in this case I'd say it's not that critical for most of people. – Neurotransmitter Sep 30 '20 at 12:35
57

An easier solution:

1.- ssh user@host

2.- $ sudo --preserve-env=DISPLAY -s

3.- # xauth merge /home/user/.Xauthority

That’s all

GreatEmerald
  • 103
  • 4
Juan
  • 571
  • 4
  • 2
  • 1
    This sounds promising but a bit incomplete. Would you mind to add info regarding how exactly to set `$DISPLAY` variable? I believe this small addition will cast additional voices to your answer. – Neurotransmitter May 06 '15 at 19:16
  • This worked for me, while @TranslucentCloud's answer did not. I originally encountered the problem while trying to run the Android SDK manager as root from the command line FYI. – scottysseus Oct 12 '15 at 14:06
  • 3
    This didn't work out of the box for me since `xauth: file /root/.Xauthority does not exist` – tdc Oct 13 '15 at 20:17
  • 5
    tdc, that's just a warning, not an error, xauth will create the file - if you run the command a second time you won't see it. – Vladimir Panteleev Jan 25 '16 at 08:53
  • 1
    Who needs to learn anything when you can just copy and paste! Thanks! Way easier. – Allison Oct 24 '17 at 15:51
9

My needs were slightly different so I came up with a slightly different solution. I needed the ability to run an X11 app as another user (who is not root). Running CentOS, so I don't have the sweet gksudo tool the lucky dogs with ubuntu have which does the Xauth magic.

I really didn't want to break out some custom scripts just to login, switch user and run an app; that seems a bit superfluous to me.

Step One:

Allow $XAUTHORITY to be carried across sudo sessions.

Add this line under the rest of the env_keep statements in /etc/sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Step Two:

Allow your target user the ability to read your .Xauthority (yeah I know, scream SECURITY! all you want). For those who just want the ability to run commands as root, this can be skipped.

The target user shares the same group as me so I just turn on group read permissions:

$ chmod g+r user ~/.Xauthority

Step Three:

CentOS doesn't populate the value of $XAUTHORITY by default. Add a line to your profile (mine is ~/.bash_profile):

export XAUTHORITY=$HOME/.Xauthority

That's it. No more tweaking. No writing .XML to get PolicyKit to work. No running scripts for each login. No having to sudo twice to copy the xauth. From here on out, you can simply:

$ sudo -u user xcalc

Works great with MobaXTerm.

W Smith
  • 91
  • 1
  • 1
  • This was just what I needed to solve the problem that I was having with getting VM console on CentOS 7. I actually only needed to do Step Three for my purpose (and, of course, ensure that X11Forwarding was set to yes in /etc/ssh/sshd_config). Thanks. – darklion Dec 16 '16 at 04:33
2

Because I frequently root on a root-squashed network file share, none of the above solutions worked for me. (xubuntu 14.04). I put together the following script, which works on my system. It may work on yours. Then again, it may not, but it's free to try...

Assumption is I've ssh'd using the -Y option.

#!/bin/bash  
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
    port=${BASH_REMATCH[1]}
else
    echo "Unexpected DISPLAY $DISPLAY"
    exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*
Gerard
  • 21
  • 1
  • The line `cookie=$(xauth list|grep $h.*$port)` could match more than intended if $port happens to be part of the cookie value. Safer is: `cookie=$(xauth list) cookie=${c%% *}` or `cookie=$(xauth list |grep $h[^ ]*$port)`. – PePa Mar 07 '19 at 19:58
2

I was facing the same situation when editing the files under /etc on my raspberry pi.

sudo -E gvim ~/test.txt

worked for me.

I would be happy to learn the downside of doing that (if any). Otherwise it works hasslefree.

Duck Dodgers
  • 143
  • 1
  • 6
2

Here is a general solution using logname . I have added it to .bashrc so it is called automatically.

xauth merge /home/`logname`/.Xauthority
QT-1
  • 131
  • 3
1

You should fully switch to the target user, i.e. use "-" with su (su - standarduser ...). If not, root's X stuff will be dragged around in environment.

Jerry Epas
  • 349
  • 3
  • 11
1

In my case, when I encountered that error, I had an encrypted user directory. After calling ecrypt-mount-private, it got rid of the error and allowed me to continue X11 forwarding.

To determine if your home folder is encrypted, you can try this (as per this answer): ls -A /home. If you see a .ecryptfs folder, then your home directory is probably encrypted, in which case you can try doing the command I put in the start of the answer.

henry
  • 11
  • 1
0

A nice one liner:

sudo xauth add `xauth list $DISPLAY`
Antoine
  • 1