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

53

Как пользователь 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? Как я могу отключить это сообщение об ошибке?

Стефан М
источник
Запустите команду еще раз и добавьте -vк ssh параметры, затем вставьте вывод в ваш вопрос.
Дженни Д

Ответы:

80

Похоже, вашему корню не хватает какого-то волшебного печенья 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.

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

TranslucentCloud
источник
Интересно. Я попробовал это, но у меня это тоже не сработало. В моем конкретном случае я могу запустить почти все (другой xterm, VirtualBox), но я не могу запустить gedit (я получаю ту же ошибку). Однако, если я переключусь на root, то смогу запустить gedit. Я следовал инструкциям к письму, но ничего. Что-то еще должно быть неправильно.
luis.espinal
@ luis.espinal надеюсь, кто-то предложит решение вашей конкретной проблемы.
TranslucentCloud
1
Длинная версия работала, как талисман, но короткая версия с ошибками в centos гласила: «xauth: (argv): 1: bad» add «командная строка»
Сэм
1
у меня на centos работала короткая версия 7
tdc
1
на Ubuntu 18.04.1 короткая версия работает нормально.
Симакис Панагиотис,
38

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

1.- ssh user@host

2.- $ sudo su

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

Вот и все

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

Juan
источник
1
Это звучит многообещающе, но немного не полностью. Не могли бы вы добавить информацию о том, как именно установить $DISPLAYпеременную? Я верю, что это небольшое дополнение добавит дополнительные голоса к вашему ответу.
TranslucentCloud
Это сработало для меня, а ответ @ TranslucentCloud - нет. Первоначально я столкнулся с проблемой при попытке запустить Android SDK manager от имени пользователя root из командной строки.
scottyseus
2
Это не сработало для меня с тех порxauth: file /root/.Xauthority does not exist
ТДЦ
2
tdc, это просто предупреждение, а не ошибка, xauth создаст файл - если вы запустите команду во второй раз, вы ее не увидите.
Владимир Пантелеев
1
Кому нужно чему-то научиться, когда можно просто скопировать и вставить! Спасибо! Намного проще.
Сирены
7

Мои потребности немного отличались, поэтому я нашел немного другое решение. Мне нужна была возможность запустить приложение 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.

W Smith
источник
Это было как раз то, что мне было нужно для решения проблемы, возникающей у меня с получением консоли VM на CentOS 7. На самом деле мне нужно было только выполнить третий шаг для своих целей (и, конечно же, убедиться, что для X11Forwarding было установлено значение yes в / etc / SSH / sshd_config). Благодарю.
Darklion
Потрясающие! Это ответ! Спасибо @W Смит
tmow
1

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

Джерри Эпас
источник
0

Поскольку я часто выполняю 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 $*
Gerard
источник
Строка cookie=$(xauth list|grep $h.*$port)может соответствовать больше, чем предполагалось, если $ port окажется частью значения cookie. Безопаснее это: cookie=$(xauth list) cookie=${c%% *}или cookie=$(xauth list |grep $h[^ ]*$port).
Пепа
0

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

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

Генри
источник