Вопрос или проблема
Прежде всего, что я хочу сделать:
Я хочу войти на сервер через ssh
. Затем сменить пользователя через sudo su user
и запустить некоторое приложение на моем экране.
Некоторые коллеги делают это, выполняя
su user
export DISPLAY=<IP>:0
и это работает.
Я подключаюсь к серверу через ssh -X user@server
. Затем я запускаю X11 приложение. Это работает хорошо (хотя и есть предупреждения).
Предупреждения:
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
qt.qpa.xcb: QXcbConnection: XCB error: 1 (BadRequest), sequence: 414, resource id: 1897, major code: 155 (Unknown), minor code: 1
Если я выполняю sudo su
(или sudo su user
) и запускаю программу или выполняю ее через sudo myprogram
, появляется ошибка.
Ошибка:
X11 connection rejected because of wrong authentication.
qt.qpa.xcb: could not connect to display localhost:11.0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
Aborted
Я нашел несколько статей об этой проблеме.
X11 пересылка не работает при смене пользователей
SSH-соединение. X11 соединение отклонено из-за неверной аутентификации
Дополните файл /etc/pam.d/su
и файл /etc/pam/sudo
записью:
session optional pam_xauth.so
Позже я изменил /etc/ssh/sshd_config
, добавив:
X11Forwarding yes
и перезапустил sshd командой systemctl restart ssh.service
. ssh -T
говорит x11forwarding yes
Но ничего не изменилось.
Кто-нибудь знает, что делать? Важно проверить некоторые изменения в пользовательских конфигурациях программ после внесения изменений.
Так как многие люди обратятся сюда с таким же сообщением об ошибке, не понимая, что это не связано с использованием su
, я хотел бы отметить, что похожие симптомы теперь возникают по совсем другой причине:
Все, что установлено с помощью Snap, не будет работать. Так, xeyes
и xclock
могут работать, но новая установка chromium-browser
или firefox
на Ubuntu не сработает.
Обходной путь – просто выполнить: export XAUTHORITY=$HOME/.Xauthority
перед запуском удаленного X11 приложения.
Необезопасный вариант:
На хосте, с которого вы входите, выполните
xhost +
или, только немного более безопасный
xhost <IP, к которому вы хотите войти>
Это позволит подключение с удаленного хоста.
Почему это небезопасно? Любая программа и пользователь с этого хоста (или любая программа/пользователь с любого хоста при xhost +
) смогут получить доступ к вашему экрану и считать все нажатия клавиш на машине, на которой вы выполняете xhost
.
Более безопасный вариант:
Добавьте ключ авторизации для вашего X11 сервера на удаленную машину:
На локальной машине, получите необходимый “волшебный куки”:
# xauth list
hostname/unix:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
На удаленной машине, добавьте секрет в ваш файл ~/.Xauthority
, проще всего снова с xauth
:
# setenv DISPLAY <IP ИСТОЧНИКА>:0
# xauth add <IP ИСТОЧНИКА>:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
Обратите внимание, что данные протокола X11 между этими машинами по-прежнему не зашифрованы и поэтому подвержены атакам.
Предположим, что user1 – это оригинальный пользователь (чей пароль вам известен), а user2 – целевой пользователь (пароль которого неизвестен). Я смог получить это следующим образом:
% ssh -Y user1@target-box
Password: xxxxxxxxxxxxx
user1@target-box% sudo -u user2 bash
Password: xxxxxxxxxxxxx
user2@target-box% cp ~user1/.Xauthority ~user2
user2@target-box% xterm &
Обратите внимание, что это также предполагает правильную конфигурацию sshd, о которой вы упомянули в вашем сообщении.
.
Ответ или решение
Ошибка "X11 connection rejected because of wrong authentication" часто возникает при попытке использования X11-форвардинга через SSH, особенно в ситуациях, когда происходит смена пользователей через sudo
или su
. Давайте разберем данную ситуацию более подробно, рассмотрим возможные причины и приведем пути решения.
Теория
X11-форвардинг позволяет запускать приложения с графическим интерфейсом на удаленном сервере и отображать их на локальном компьютере. При использовании SSH параметр -X
или -Y
активирует форвардинг X11. При этом валидация и авторизация соединений осуществляется с помощью механизма xauth (X11-авторизация), который использует "магические куки" для управления доступом к X-серверу.
Ситуация усложняется, когда вы переключаете пользователей на сервере при помощи команд sudo
или su
. В этот момент механизм xauth может потерять контекст текущей авторизации, что и вызывает проблему с аутентификацией.
Пример
В приведенном сценарии вы подключаетесь к серверу с использованием команды ssh -X user@server
, и затем допускаете смену пользователей для запуска приложения. В этом случае возникают следующие предупреждения и ошибки:
- Предупреждения: такие, как
libEGL warning
, указывают на проблемы с графическими библиотеками, но они не критичны для работы X11-форвардинга. - Основная ошибка: "X11 connection rejected because of wrong authentication" говорит о том, что текущий пользователь не имеет авторизации для доступа к окнам.
Применение
Рассмотрим решения, которые могут исправить данную ситуацию:
-
Настройка PAM (Pluggable Authentication Modules):
- Добавление строки
session optional pam_xauth.so
в файлыпам.d/su
ипам.d/sudo
поможет автоматически экспортировать xauth-картинки при переключении пользователей. Однако, если уже применено и не решило проблему, вероятно существует другая причина.
- Добавление строки
-
Настройка SSHD:
- Убедитесь, что в файле
/etc/ssh/sshd_config
активирован параметрX11Forwarding yes
. - Перезапускайте SSH-демон после внесения изменений командой
systemctl restart sshd
.
- Убедитесь, что в файле
-
Импорт xauth-кода вручную:
- Скопируйте xauth-картинки вручную из домашнего каталога одного пользователя в другой.
- На локальной машине выполните
xauth list
, чтобы увидеть "магические куки". - На удаленной машине добавьте их с помощью команды
xauth add
.
-
Настройка переменной среды XAUTHORITY:
- Перед запуском приложения используйте
export XAUTHORITY=$HOME/.Xauthority
, чтобы явно указать путь к файлу аутентификации.
- Перед запуском приложения используйте
-
Использование
xhost
(небезопасный метод):- Вы можете использовать
xhost +
для отключения ограничений доступа. Это позволит всем клиентам подключаться без аутентификации, но это крайне небезопасно.
- Вы можете использовать
-
Snap-приложения:
- Если вы используете Snap для установки приложений, они могут не работать с X11-форвардингом. Решение — использовать
export XAUTHORITY=$HOME/.Xauthority
перед запуском приложения.
- Если вы используете Snap для установки приложений, они могут не работать с X11-форвардингом. Решение — использовать
Все эти шаги помогают управлять и настраивать доступ к X11 для разных пользователей, несмотря на ограниченность приборов аутентификации. Важно осознавать риски некоторых решений и применять их в соответствующих условиях, например, при внутрикорпоративной разработке на изолированных системах.
Понимание внутренней логики X11-форвардинга и корректное управление аутентификацией между пользователями позволяет избежать проблем с доступом и использовать возможности удаленного использования графических интерфейсов в полной мере.