Соединение X11 отклонено из-за неправильной аутентификации.

Вопрос или проблема

Прежде всего, что я хочу сделать:

Я хочу войти на сервер через 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" говорит о том, что текущий пользователь не имеет авторизации для доступа к окнам.

Применение

Рассмотрим решения, которые могут исправить данную ситуацию:

  1. Настройка PAM (Pluggable Authentication Modules):

    • Добавление строки session optional pam_xauth.so в файлы пам.d/su и пам.d/sudo поможет автоматически экспортировать xauth-картинки при переключении пользователей. Однако, если уже применено и не решило проблему, вероятно существует другая причина.
  2. Настройка SSHD:

    • Убедитесь, что в файле /etc/ssh/sshd_config активирован параметр X11Forwarding yes.
    • Перезапускайте SSH-демон после внесения изменений командой systemctl restart sshd.
  3. Импорт xauth-кода вручную:

    • Скопируйте xauth-картинки вручную из домашнего каталога одного пользователя в другой.
    • На локальной машине выполните xauth list, чтобы увидеть "магические куки".
    • На удаленной машине добавьте их с помощью команды xauth add.
  4. Настройка переменной среды XAUTHORITY:

    • Перед запуском приложения используйте export XAUTHORITY=$HOME/.Xauthority, чтобы явно указать путь к файлу аутентификации.
  5. Использование xhost (небезопасный метод):

    • Вы можете использовать xhost + для отключения ограничений доступа. Это позволит всем клиентам подключаться без аутентификации, но это крайне небезопасно.
  6. Snap-приложения:

    • Если вы используете Snap для установки приложений, они могут не работать с X11-форвардингом. Решение — использовать export XAUTHORITY=$HOME/.Xauthority перед запуском приложения.

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

Понимание внутренней логики X11-форвардинга и корректное управление аутентификацией между пользователями позволяет избежать проблем с доступом и использовать возможности удаленного использования графических интерфейсов в полной мере.

Оцените материал
Добавить комментарий

Капча загружается...