Cuando ingreso a un servidor remoto que no ejecuta ningún tipo de entorno de escritorio X11, recibo el siguiente mensaje.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

¿Cómo puedo deshacerme de estos mensajes?

Estos mensajes se pueden eliminar mediante 1 de 3 métodos, utilizando solo las opciones SSH. Siempre puede enviar mensajes /dev/nulltambién, pero estos métodos intentan manejar el mensaje a través de la configuración, en lugar de simplemente atraparlos y deshacerse de ellos.

Método # 1 - instale xauth

El servidor al que se está conectando remotamente se queja de que no puede crear una entrada en el .Xauthorityarchivo del usuario , porque xauthno está instalado. Por lo tanto, puede instalarlo en cada servidor para deshacerse de este mensaje molesto.

En Fedora 19 instalas xauthasí:

$ sudo yum install xorg-x11-xauth

Si luego intentas sshingresar al servidor, verás un mensaje de que se está creando una entrada en el .Xauthorityarchivo del usuario .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Los inicios de sesión posteriores ya no mostrarán este mensaje.

Método 2: deshabilítelo a través de ForwardX11

Puede indicar al sshcliente que no intente habilitar el reenvío X11 mediante la inclusión del parámetro SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Puede hacer lo mismo con el -xinterruptor:

$ ssh -x root@server

Esto solo desactivará temporalmente este mensaje, pero es una buena opción si no puede o no desea instalar xauthen el servidor remoto.

Método 3: deshabilítelo a través de sshd_config

Este suele ser el valor predeterminado, pero en caso de que no lo sea, puede configurar su sshdservidor para que X11Forwarding esté apagado, en /etc/ssh/sshd_config.

X11Forwarding no

De los 3 métodos que generalmente uso # 2, porque a menudo querré usar la X11Forwardingmayoría de mis servidores, pero luego no quiero ver las X11....advertencias

$ HOME / .ssh / config

La mayoría de las veces, este mensaje ni siquiera aparece. Por lo general, solo están presentes cuando tiene las siguientes entradas en su $HOME/.ssh/configarchivo, en la parte superior.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Por lo tanto, es esta configuración, la que en última instancia está impulsando la generación de esos X11..mensajes, por lo que nuevamente, el método # 2 parece ser el más apropiado si desea operar ForwardX11 yesde manera predeterminada, pero luego lo deshabilita selectivamente para ciertas conexiones desde la sshperspectiva del cliente .

Seguridad

En general, es desaconsejable ejecutar ForwardX11 yesen todo momento. Entonces, si desea operar sus conexiones SSH de la manera más segura posible, es mejor hacer lo siguiente:

1. No incluir ForwardX11 yesen tu $HOME/.ssh/configarchivo
2. Solo use ForwardingX11 cuando necesite ssh -X user@server
3. Si puede, deshabilite X11Forwardingcompletamente en el servidor para que no se permita

Referencias

• SSH: The Secure Shell - La guía definitiva - 9.3. X reenvío

En mi caso, agregar esta cadena para /etc/ssh/sshd_configresolver el problema:

X11UseLocalhost no

Me encontré con esto hoy y me golpeé la cabeza por un tiempo hasta que me topé con una configuración ssh:

Si es RHEL 7 (centOS, OEL, etc.) y tiene ipv6 deshabilitado, necesita:

AddressFamily inet

establecido en / etc / ssh / sshd_config.

Otra ligera variación sería si quisiera dejar de ver este mensaje (es decir, dejar de intentar reenviar X11) para ciertos servidores pero mantener el valor predeterminado de ForwardX11 yes para todas las demás conexiones.

Para este escenario, puede deshabilitar el reenvío X11 para un host específico (o rango) en su ~ / .ssh / config. Algo como esto:

host 10.1.1.*
ForwardX11 no 

Reconocimiento: Este es un ligero adorno a la respuesta existente (y muy completa) existente, ¡ya que no pude comentar!

Si ejecutar el cliente en modo detallado ( ssh -v user@host) le da

debug1: Remote: No xauth program; cannot forward with spoofing.

pero de xauthhecho está instalado en el servidor, probablemente se deba a que sshd busca el ejecutable xauth en una ubicación incorrecta ( / usr / X11R6 / bin / xauth generalmente). Uno puede arreglar eso configurando

XAuthLocation /usr/bin/xauth

en / etc / sshd / sshd_config (o lo que sea que esté configurado su servidor).

Configuración de reenvío X11 por host

Además de todas las excelentes respuestas que ya están aquí, puede configurarlas ForwardX11por host, por lo que si solo serverfalla así, puede agregar una entrada a su ~/.ssh/configarchivo de la siguiente forma:

Host server server.domain.dom
    ForwardX11 no

Incluso puede usar entradas como esta como alias para conjuntos completos de configuraciones

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Esto es especialmente útil si ha configurado los nombres de servidor de Autocompletar para SSH y SCP .

Me encontré con esta pregunta después de una carrera con un sshd-xautherror de casi una década. Se informan dos soluciones, la primera evitando xauth, la segunda abordando el error.

Solución 1 - bypass xauth

• 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.

También publiqué esta solución como respuesta a otra pregunta.

Solución 2: solucione el error sshd / xauth

Esta solución está cerca de la solución de @systempoet anterior , aunque eso por sí solo no fue suficiente.

Además de modificar /etc/ssh/sshd_configen remoto:

AddressFamily inet

/etc/hosts en remoto también fue modificado:

::1     localhost ip6-localhost ip6-loopback

Si alguno de ellos fue comentado, el mensaje de error

X11 forwarding request failed on channel 0

apareció después de la ssh -X ...llamada. Además, /var/log/auth.logmostró el error:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Prueba para producir el error (antes de la corrección):

Máquina local:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

Un punto importante a tener en cuenta después de realizar los cambios de configuración es que tendrá que eliminar sshd para que recoja los cambios:

cat /var/run/sshd.pid | xargs kill -1

siendo el usuario root.

1. Establezca las siguientes 2 opciones /etc/ssh/sshd_configen su host RHEL

   X11Forwarding yes X11UseLocalhost no

2. sudo /etc/init.d/sshd reload

3. sudo yum install xauth
4. ssh de vuelta a su host RHEL con el interruptor -X: ssh -X yourname@rhelbox