Primero que nada lo que quiero hacer:
Quiero iniciar sesión en un servidor mediante ssh. Luego cambie el usuario sudo su usere inicie alguna aplicación en mi pantalla.
Algunos colegas lo hacen por
su user
export DISPLAY=<IP>:0
y funciona.
Me conecto a un servidor mediante ssh -X user@server. Luego inicio una aplicación X11. Esto funciona bien (aunque hay advertencias).
Advertencias:
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
Si ejecuto sudo su(o sudo su user) e inicio el programa o lo ejecuto, sudo myprogramhay un error.
Error:
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
Encontré algunos artículos sobre este problema.
El reenvío X11 falla al cambiar de usuario
conexión ssh. Conexión X11 rechazada debido a una autenticación incorrecta
Así que extienda el /etc/pam.d/suarchivo y el /etc/pam/sudoarchivo por
session optional pam_xauth.so
Y luego cambié /etc/ssh/sshd_configagregando:
X11Forwarding yes
y reiniciando el sshd por systemctl restart ssh.service. ssh -Tdicex11forwarding yes
Pero nada cambió.
¿Alguien sabe qué hacer? Es importante verificar algunos cambios en las configuraciones del programa de los usuarios después de realizar cambios.
Respuesta1
Dado que muchas personas vendrán aquí con el mismo mensaje de error, sin darse cuenta de que no está relacionado con el uso de su, me gustaría señalar que ahora ocurren síntomas similares por una razón muy diferente:
Todo lo que se instale con Snap no funcionará. Entonces xeyesy xclockpodría funcionar, pero una nueva instalación de chromium-browserUbuntu firefoxno funcionará.
La solución es simplemente hacer: export XAUTHORITY=$HOME/.Xauthorityantes de ejecutar la aplicación X11 remota.
Respuesta2
Inseguroopción:
En el host desde el que inicia sesión, ejecute
xhost +
o, sólo un poco más seguro
xhost <IP you want to log in to>
Esto permitirá conexiones desde el host remoto.
¿Por qué es esto inseguro? Cualquier programa y usuario de ese host (o cualquier programa/usuario de cualquier host, con xhost +) podrá acceder a su pantalla y leer todas las pulsaciones de teclas en la máquina xhosten la que ejecuta.
Más seguroopción:
Agregue la clave de autorización para su servidor X11 a la máquina remota:
En la máquina local, enumere la "cookie mágica" necesaria:
# xauth list
hostname/unix:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
En la máquina remota, agregue el secreto a su ~/.Xauthorityarchivo, lo más fácil nuevamente con xauth:
# setenv DISPLAY <ORIGIN_IP>:0
# xauth add <ORIGIN_IP>:0 MIT-MAGIC-COOKIE-1 0123456789abcdef0123456789abcdef
Tenga en cuenta que los datos del protocolo X11 entre estas máquinas aún no están cifrados y, por lo tanto, son propensos a ataques.
Respuesta3
Suponiendo que el usuario1 es el usuario original (cuya contraseña conoce) y el usuario2 es el usuario objetivo (contraseña desconocida), puedo hacer que esto funcione:
% 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 &
Tenga en cuenta que esto también supone la configuración sshd correcta que usted explicó en su publicación.