Прежде всего, что я хочу сделать:
Я хочу войти на сервер через 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
Но ничего не изменилось.
Кто-нибудь знает, что делать? Важно проверить некоторые изменения в конфигурациях программ пользователей после внесения изменений.
решение1
Поскольку многие люди придут сюда с тем же сообщением об ошибке, не понимая, что это не связано с использованием su, я хотел бы отметить, что похожие симптомы теперь возникают по совершенно другой причине:
Все, что установлено с помощью Snap, работать не будет. Так что xeyesи xclockможет работать, но новая установка chromium-browserили firefoxна Ubuntu работать не будет.
Обходной путь — просто сделать: export XAUTHORITY=$HOME/.Xauthorityперед запуском удаленного приложения X11.
решение2
Ненадежныйвариант:
На хосте, с которого вы входите в систему, выполните
xhost +
или, только немного более безопасно
xhost <IP you want to log in to>
Это позволит устанавливать соединения с удаленного хоста.
Почему это небезопасно? Любая программа и пользователь с этого хоста (или любая программа/пользователь с любого хоста, с xhost +) смогут получить доступ к вашему экрану и прочитать все нажатия клавиш на машине, xhostна которой вы работаете.
Более безопасныйвариант:
Добавьте ключ авторизации для вашего сервера X11 на удаленную машину:
На локальной машине перечислите необходимые «волшебные куки»:
# xauth list
hostname/unix:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
На удаленной машине добавьте секрет в свой ~/.Xauthorityфайл, проще всего снова сделать так xauth:
# setenv DISPLAY <ORIGIN_IP>:0
# xauth add <ORIGIN_IP>:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
Обратите внимание, что данные протокола X11 между этими машинами по-прежнему не зашифрованы и поэтому подвержены атакам.
решение3
Предполагая, что 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, указанную вами в своем посте.