Respuestas:
Puede crear una segunda conexión con el reenvío X11 habilitado, y luego también puede usar la DISPLAY
variable de entorno de la segunda conexión en la primera.
En la primera ventana:
$ ssh user@host
user@host$ ...
En la segunda ventana:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Volver a la primera ventana:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Desafortunadamente, ssh
no hace nada para contener los reenvíos X11 (u otros) al proceso / sesión que inició o al usuario que ejecuta como en la máquina remota (por ejemplo, usando sockets Unix con / sin verificación de credenciales, o usando espacios de nombres), y esos reenvíos son simples enchufes de escucha tcp a los que cualquiera en la máquina remota puede conectarse; Toda la seguridad del reenvío X11 se basa en la autenticación X11.
La página de sshd_config(5)
manual menciona que:
deshabilitar el reenvío X11 no impide que los usuarios reenvíen el tráfico X11, ya que los usuarios siempre pueden instalar sus propios reenviadores.
Así es como puedes hacer eso a mano.
En primer lugar, asegúrese de deshabilitar cualquier control de acceso basado en el host o el usuario que omita el mecanismo de autenticación x11 [1]:
$ xhost $(xhost | sed -n /:/s/^/-/p)
access control enabled, only authorized clients can connect
Luego muestre la información de autenticación para DISPLAY=:0
en la máquina local:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Conéctese a la máquina remota sin ningún reenvío X11:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Abra la línea de comando vía ~C
y agregue un reenvío remoto desde el puerto 6000+43
al zócalo Unix correspondiente a la pantalla :0
:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Configure el $DISPLAY
envvar y agregue la información de autenticación de la máquina local a la remota:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Ahora estás listo para comenzar:
hzy64$ xterm
[1] debido a una corrección de errores equivocada , el control de acceso basado en el usuario está activado por defecto en Debian a través de /etc/X11/Xsession.d/35x11-common_xhost-local
. Peor aún, es el único disponible de forma predeterminada en XWayland, donde tampoco se puede desactivar . Cualquier programa que represente el protocolo X11 (p. Ej. xscope
) Tendrá que hacer su propia comprobación de cookies de autenticación x11 (como lo hace ssh), a menos que quiera abrir un agujero en el servidor X11.
-X
sería un poco mejor que -Y
, ¿no?
-X
, solo con -Y
. la gente no lo nota porque en muchos sistemas (por ejemplo, debian) ForwardX11Trusted
está configurado yes
de forma predeterminada, y las opciones -X
y -Y
son equivalentes ;-)
change $DISPLAY to
. El título de la pregunta actual no se puede mostrar en su totalidad en los resultados de búsqueda, y cambiar $ DISPLAY es realmente parte de la respuesta, no parte de la pregunta.