Reenviar X11 sobre SSH si la configuración del servidor no lo permite

10

Considere una situación en la que estoy iniciando sesión a través de SSH de la máquina A a la máquina B, tengo una sesión X en la máquina A y quiero ejecutar un programa X en B.

ssh -X Bhace que esto funcione de manera transparente. Pero, ¿qué X11Forwarding yespasa si la configuración del servidor carece , no tengo permisos de root en el servidor y el administrador del servidor es indiferente?

Obviamente, es posible reenviar la conexión X11, ya que puedo transferir lo que quiera a través del canal SSH. De hecho, si el servidor X local permite conexiones TCP, es tan fácil como ssh -R 6010:localhost:6000(ser ajustado para los números de pantalla). ¿Qué pasa con el caso común en el que el servidor X local solo permite conexiones de socket? ¿Cómo hago el reenvío X de manera conveniente y segura, con un mínimo de requisitos de instalación (especialmente en B)?

ssh xorg xforwarding Gilles 'SO- deja de ser malvado'
fuente

Respuestas:

2

La respuesta de @Demi es buena, pero creo que completarla sería de gran ayuda.

  • local: la máquina local que sirve un Xserver.
  • remoto: la máquina remota que sirve a la aplicación que dirige los datos que van al servidor X

Remoto /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

El control remoto ~/.Xauthorityestá vacío o no existe

En local:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

En la prueba, local ejecutaba Ubuntu 18.05, remoto ejecutaba Debian Jesse.

Craig Hicks
fuente
5

¿El protocolo X11 habla cuando habla con un puerto tcp diferente al hablar con un socket?

Tal vez podría combinar su propio uso sugerido ssh -R 6010:localhost:6000para traer los datos X11 a través del reenvío de puertos, luego unir el gab local entre el puerto tcp y el escucha del socket X11 con nc como:

nc -l -p 6000 > /tmp/.X11-unix/X0
Caleb
fuente
Sí, esa es la idea. Pero esperaba una respuesta que diga "ponga esto en su .ssh/configlado del cliente y aquello en su .profilelado del servidor, y luego simplemente ejecute ssh B".
Gilles 'SO- deja de ser malvado'
1
Hay una respuesta fácil de "poner esto en su configuración", el problema es que descarta eso en sus calificaciones de preguntas porque la opción que necesita va en el lado sshd_config de las cosas en B. Está tratando de evitar un bloque puesto en lugar para dificultar la apertura inadvertida de un problema de seguridad.
Caleb
3
Estoy apuntando al caso (en mi experiencia muy común) en el que al administrador no le importa y simplemente dejó la configuración predeterminada en su lugar. El reenvío X11 no está prohibido por la política, es solo un inconveniente por la indiferencia del administrador del sistema. De todos modos, el reenvío X11 permite que el servidor ataque al cliente, por lo que prohibirlo del lado del servidor no tiene mucho sentido.
Gilles 'SO- deja de ser malvado'
@Gilles Estoy de acuerdo en que el valor predeterminado realmente no protege contra nada útil. Entonces, ¿deberíamos presionar para que se cambie el valor predeterminado?
Caleb,
Para mí, /tmp/.X11-unix/X0es un socket de dominio Unix, no un FIFO, por lo que cualquier intento de redirección termina con ENXIO: No such device.
Samveen
2

  1. Gire un servidor X adicional usando Xephyr. Esto es por seguridad: evita que el sistema remoto comprometa el suyo.

  2. Use SSH para reenviar un zócalo remoto al zócalo Xephyr. SSH también admite el reenvío de sockets Unix.

  3. Establezca las variables de entorno en el servidor remoto correctamente.

Demi
fuente