"Su" з помилкою "З’єднання X11 відхилено через неправильну аутентифікацію"

Як root, я підключаюсь до віддаленого хоста, щоб виконати команду. Тільки "standardduser" має відповідний id-файл та правильний .ssh / config, тому я спочатку перемикаю користувача:

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

Команда працює чудово, але, незважаючи на те, що я використав "-x" (вимкнути X11-Forwarding) і відключив X11Forwards /etc/ssh/ssh_config, я все одно отримую повідомлення про помилку:

X11 connection rejected because of wrong authentication.

Я не отримую повідомлення про помилку, коли я ввійшов як "standardduser".

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

Чому "ssh -x" не вимикає з’єднання X11 та передає повідомлення про помилку?

ОНОВЛЕННЯ : Повідомлення відображається лише під час входу в екран, при використанні команди, зазначеної вище на самій локальній машині (без екрана), я не отримую повідомлення про помилку, тому це має бути добре і з cron .

Я також запустив ту саму команду -vі напрочуд отримав повідомлення про помилку ПЕРШЕ, ще до того, як інформація про стан 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? Як я можу відключити це повідомлення про помилку?

Схоже , ваш корінь не вистачає яке - то Х11 чарівного печива в .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.

Останнє, що потрібно зробити, - це додати саме це печиво до кореня .Xauthority. Увійдіть як корінь і виконайте наступне:

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 протягом судових сесій.

Додайте цей рядок під рештою операторів env_keep в / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION 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 ...). Якщо ні, 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папку, то ваш домашній каталог, ймовірно, зашифрований, і в цьому випадку ви можете спробувати виконати команду, яку я поставив на початку відповіді.