«Su» с ошибкой «X11 соединение отклонено из-за неправильной аутентификации»

Как пользователь root я подключаюсь к удаленному хосту для выполнения команды. Только "standarduser" имеет соответствующий id-файл и правильный .ssh / config, поэтому я сначала переключаю пользователя:

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

Команда работает нормально, но, несмотря на то, что я использовал «-x» (отключить пересылку X11) и отключил X11Forwards /etc/ssh/ssh_config, я все равно получаю сообщение об ошибке:

X11 connection rejected because of wrong authentication.

Я не получаю сообщение об ошибке, когда я вошел как "standarduser".

Это довольно раздражает, так как я хотел бы интегрировать команду в файл задания cron. Я понимаю, что сообщение об ошибке относится к неверной аутентификации корневого файла .XAuth, но я даже не пытаюсь подключиться через X11.

Почему «ssh -x» не отключает соединение X11 и не выдает сообщение об ошибке?

ОБНОВЛЕНИЕ : сообщение отображается только когда я вошел в систему на экране, при использовании команды, указанной выше, на самой локальной машине (без экрана), я не получаю сообщение об ошибке, так что это должно быть хорошо с cron, тоже ,

Я также запустил ту же команду -vи неожиданно получил сообщение об ошибке FIRST, даже до получения информации о состоянии из 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

Это привело меня к самой проблеме, это не то, sshчто выдает сообщение об ошибке, это su:

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

Почему я получаю только эту ошибку внутри screen? Как я могу отключить это сообщение об ошибке?

Похоже, вашему корню не хватает какого-то волшебного печенья X11 в том .Xauthority, что у вас standarduserесть. Вот как это исправить.

КОРОТКАЯ ВЕРСИЯ (спасибо @bmaupin )

standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`

Внимание: проверьте галочки! Их нельзя заменить кавычками! Вам нужно sudoустановить, чтобы продолжить дальше вторая команда!

ОРИГИНАЛЬНАЯ ДЛИННАЯ ВЕРСИЯ

Чтобы исправить ситуацию, сначала определите, какой номер дисплея standarduserиспользует:

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

В этом случае это так 21.0. Во-вторых, отобразить standarduserсписок файлов cookie:

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

Файл cookie для 21.0дисплея является вторым в списке и заканчивается на 104f.

Последнее, что нужно сделать, это добавить этот файл cookie в корневой каталог .Xauthority. Войдите в систему как пользователь root и сделайте следующее:

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

Вот как вы можете уменьшить X11 connection rejected because of wrong authenticationошибку, когда вы запускаете suдругого пользователя в скрипте Bash или screen.

Спасибо этому парню за вдохновение.

Более простое решение:

1.- ssh user@host

2.- $ sudo su

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

Вот и все

Конечно, $DISPLAYпеременная должна быть установлена.

Мои потребности немного отличались, поэтому я нашел немного другое решение. Мне нужна была возможность запустить приложение X11 от имени другого пользователя (который не является пользователем root). Запуск CentOS, так что у меня нет сладкого инструмента gksudo, который есть у счастливых собак с ubuntu, который делает магию Xauth.

Я действительно не хотел запускать некоторые пользовательские скрипты только для входа в систему, переключения пользователей и запуска приложения; это кажется немного излишним для меня.

Шаг первый:

Разрешить перенос $ XAUTHORITY между сеансами sudo.

Добавьте эту строку под остальными операторами env_keep в / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Шаг второй:

Позвольте вашему целевому пользователю возможность читать ваш .Xauthority (да, я знаю, кричать БЕЗОПАСНОСТЬ! Все, что вы хотите). Для тех, кто просто хочет запускать команды от имени root, это можно пропустить.

Целевой пользователь имеет ту же группу, что и я, поэтому я просто включаю права на чтение группы:

$ chmod g+r user ~/.Xauthority

Шаг третий:

CentOS не заполняет значение $ XAUTHORITY по умолчанию. Добавьте строку в свой профиль (у меня ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

Вот и все. Нет больше настройки. Не надо писать .XML, чтобы заставить PolicyKit работать. Нет запущенных скриптов для каждого логина. Нет необходимости дважды судить, чтобы скопировать xauth. С этого момента вы можете просто:

$ sudo -u user xcalc

Прекрасно работает с MobaXTerm.

Вы должны полностью переключиться на целевого пользователя, т.е. использовать " -" с su( su - standarduser ...). Если нет, то root-файлы X будут перемещаться в среде.

Поскольку я часто выполняю root-доступ к сетевому файлу общего доступа, ни одно из перечисленных выше решений не работает для меня. (xubuntu 14.04). Я собрал следующий скрипт, который работает в моей системе. Это может работать на вашем. Опять же, это не так, но это можно попробовать бесплатно ...

Предполагается, что я ssh'd с помощью опции -Y.

#!/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 $*

В моем случае, когда я столкнулся с этой ошибкой, у меня был зашифрованный каталог пользователя. После звонка ecrypt-mount-privateон избавился от ошибки и позволил мне продолжить пересылку X11.

Для того, чтобы определить , является ли ваша домашняя папка зашифрованы, вы можете попробовать это (как за этот ответ ): ls -A /home. Если вы видите .ecryptfsпапку, то ваш домашний каталог, вероятно, зашифрован, и в этом случае вы можете попробовать выполнить команду, указанную в начале ответа.