X11 forwarding: ssh -X frente a -Y, sshd_config y alternativas

X11 forwarding por SSH permite ejecutar una aplicación gráfica en un servidor Linux y ver su ventana en tu equipo local. Tiene sentido cuando necesitas una herramienta gráfica puntual y tu cliente dispone de servidor X. Usa ssh -X por defecto, -Y solo con servidores de plena confianza, y activa X11Forwarding yes en sshd_config.

ssh -X frente a ssh -Y: qué cambia en el X11 forwarding de OpenSSH

ssh -X activa el reenvío X11 tratando las aplicaciones remotas como no confiables, sujetas a los controles de la extensión X11 SECURITY. ssh -Y activa el reenvío X11 de confianza y elimina esos controles. En ambos casos el tráfico X viaja cifrado dentro de la sesión SSH y el servidor fija la variable DISPLAY para que las ventanas lleguen a tu pantalla.

La diferencia es de seguridad. La página de manual de ssh advierte que quien pueda saltarse los permisos de archivo en el servidor puede acceder a tu display local a través del reenvío y, por ejemplo, registrar pulsaciones de teclado. Con -Y ese acceso no tiene límites; con -X queda restringido, a cambio de que algunas aplicaciones fallen.

Usa -X por defecto, y siempre en servidores compartidos o que no administras tú.
Usa -Y solo si la aplicación no funciona con -X y el servidor es de plena confianza.
Revisa ForwardX11Trusted en el ssh_config del sistema: algunas distribuciones cambian su valor y -X acaba comportándose como -Y.

Cómo activar X11Forwarding en el servidor SSH y probarlo

El servidor solo acepta X11 forwarding si /etc/ssh/sshd_config contiene X11Forwarding yes y el programa xauth está instalado; si falta cualquiera de los dos, la petición del cliente se rechaza. Esta es la configuración mínima en ambos lados:

# Servidor: /etc/ssh/sshd_config
X11Forwarding yes
X11UseLocalhost yes

# Comprobar la sintaxis y recargar el servicio
sudo sshd -t
sudo systemctl reload sshd   # en Debian/Ubuntu el servicio se llama ssh

# Cliente: conexión puntual
ssh -X usuario@servidor
echo $DISPLAY                # algo como localhost:10.0
xclock &

# Cliente: ~/.ssh/config
Host lab
    HostName lab.example.com
    User usuario
    ForwardX11 yes
    ForwardX11Trusted no

Las directivas de sshd_config documentadas explican el resto: X11UseLocalhost yes hace que el display reenviado escuche solo en la interfaz local del servidor, y X11DisplayOffset fija el primer número de display que usa sshd, de ahí el :10 habitual. Si algo falla, ssh -v -X usuario@servidor muestra el motivo:

X11 forwarding request failed on channel 0: el servidor tiene X11Forwarding no o le falta xauth.
Can't open display en la aplicación: suele indicar que DISPLAY está vacía porque la sesión no pidió el reenvío o no hay servidor X local en marcha.

X11 forwarding en iOS y Android frente al escritorio: qué necesita cada lado

X11 forwarding requiere un servidor X en el equipo cliente, porque es ese equipo el que dibuja las ventanas. En un escritorio Linux suele estar disponible; en macOS hay que instalar XQuartz; un cliente SSH móvil normalmente es una terminal sin servidor X.

Qué se mide	Escritorio con ssh -X	Móvil iOS/Android	Alternativa: túnel -L o SFTP
Servidor X local	Necesario: X11, XWayland o XQuartz	Normalmente no disponible en la terminal	No hace falta
Compatibilidad con Mosh	Mosh no reenvía X11; requiere SSH	Mosh mantiene la terminal, sin ventanas X	El túnel -L requiere SSH, no Mosh
Cambio de wifi a datos	La sesión SSH y sus ventanas se cortan	Con Mosh y tmux la sesión sigue	El túnel se reabre; tmux conserva los procesos
Riesgo para el equipo local	Con -Y, acceso sin límites al display	Sin display X expuesto	Solo se expone el puerto reenviado
Uso adecuado	Herramienta gráfica puntual en red estable	Administración por terminal y archivos	Interfaces web, gráficos y documentos

termi1 es una terminal SSH, Mosh y SFTP, y Mosh, por diseño, no hace port forwarding ni X11 forwarding. Lo que resuelve en el móvil es otra cosa: mantener la sesión al pasar de wifi a datos y volver a tmux con lo que dejaste corriendo.

4 alternativas a X11 forwarding por SSH que funcionan desde el móvil

ssh -L reenvía un puerto local a un servicio del servidor y cubre muchos casos en los que antes se abría una ventana X: paneles web, notebooks o consolas que escuchan en localhost.

# Reenviar el puerto 8080 del servidor a tu equipo
ssh -N -L 8080:localhost:8080 usuario@servidor
# Después abre http://localhost:8080 en el navegador local

Túnel de puertos con ssh -L: muestra interfaces web del servidor en el navegador local, sin servidor X, en cualquier cliente que admita reenvío de puertos.
Descargar el resultado por SFTP: si la aplicación gráfica solo servía para ver un gráfico, un PDF o una imagen, genera el archivo en el servidor y bájalo. El SFTP integrado de termi1 lo hace sin salir de la sesión.
Herramientas de texto dentro de tmux: htop, journalctl o un editor en terminal sustituyen a muchos monitores gráficos. El teclado de termi1 añade Esc, Ctrl y F1–F12, que estas herramientas usan sin parar.
Escritorio remoto por red privada: si necesitas un escritorio completo, una red privada en malla Prialo o Tailscale permite llegar al equipo sin IP pública ni puertos abiertos.

Cuándo tiene sentido usar X11 forwarding por SSH en 2026

X11 forwarding compensa cuando se cumplen tres condiciones: la aplicación gráfica solo existe en el servidor, la necesitas poco tiempo y trabajas desde un escritorio con servidor X y red estable. Fuera de ese caso, las alternativas anteriores son más simples y exponen menos.

Casos razonables: un instalador gráfico, una herramienta de diagnóstico del fabricante o un visor sin versión web. Casos que conviene evitar: -Y por costumbre, ForwardX11 yes bajo Host * o X11Forwarding yes en servidores de producción que nadie usa en modo gráfico; ahí lo correcto es X11Forwarding no.

Desde el móvil, el flujo práctico es conectar con Mosh, volver a tmux y trabajar en texto. Si no recuerdas la sintaxis de ssh -L, la IA de la terminal SSH y Mosh termi1 escribe el comando en el prompt sin pulsar Intro, y en conexiones de producción Production Guard retiene lo que borra, detiene o cambia algo.

Preguntas frecuentes

¿Qué diferencia hay entre ssh -X y ssh -Y?

La diferencia entre ssh -X y ssh -Y es el nivel de confianza. -X reenvía X11 aplicando las restricciones de la extensión X11 SECURITY a las aplicaciones remotas; -Y las trata como de confianza y les da acceso completo a tu display local. Usa -Y solo con servidores que controlas.

¿Por qué aparece «X11 forwarding request failed on channel 0»?

El error «X11 forwarding request failed on channel 0» significa que el servidor rechazó el reenvío X11. Las causas habituales son X11Forwarding no en /etc/ssh/sshd_config o la falta del programa xauth en el servidor. Corrige la directiva, instala xauth, recarga sshd y abre una sesión nueva.

¿Funciona X11 forwarding con Mosh?

X11 forwarding no funciona con Mosh. Mosh usa UDP, por defecto en los puertos 60000-61000, arranca mosh-server mediante una conexión SSH inicial y no hace port forwarding ni X11 forwarding. Para abrir ventanas X necesitas una sesión SSH normal con -X o -Y.

¿Se puede usar X11 forwarding desde un iPhone o un Android?

X11 forwarding desde un iPhone o un Android solo funciona si el cliente incluye un servidor X que dibuje las ventanas, algo poco habitual en terminales móviles. En la práctica rinde más usar un túnel ssh -L hacia una interfaz web, descargar resultados por SFTP o trabajar con herramientas de texto en tmux.