GNU/Linux >> Tutoriales Linux >  >> Linux

Ssh devuelve el mensaje "Error en la solicitud de reenvío x11 en el canal 1"?

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

$ ssh [email protected]
X11 forwarding request failed

$ ssh [email protected] ls
X11 forwarding request failed on channel 1
file1
file2
...

¿Cómo puedo deshacerme de estos mensajes?

Respuesta aceptada:

Estos mensajes se pueden eliminar a través de 1 de 3 métodos, utilizando solo las opciones de SSH. Siempre puedes enviar mensajes a /dev/null también, pero estos métodos intentan lidiar con el mensaje a través de la configuración, en lugar de simplemente capturarlos y descargarlos.

Método #1:instalar xauth

El servidor al que se está conectando de forma remota se queja de que no puede crear una entrada en el .Xauthority del usuario. archivo, porque xauth no está instalado. Así que puedes instalarlo en cada servidor para deshacerte de este molesto mensaje.

En Fedora 19, instala xauth así:

$ sudo yum install xorg-x11-xauth

Si luego intenta ssh en el servidor, verá un mensaje de que se está creando una entrada en el .Xauthority del usuario archivo.

$ ssh [email protected]
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

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

Método n.º 2:desactívelo a través de ForwardX11

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

$ ssh -o ForwardX11=no [email protected]

Puedes hacer lo mismo con -x cambiar:

$ ssh -x [email protected]

Esto solo deshabilitará temporalmente este mensaje, pero es una buena opción si no puede o no quiere instalar xauth en el servidor remoto.

Método n.º 3:desactívelo a través de sshd_config

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

X11Forwarding no

De los 3 métodos, generalmente uso el n. ° 2, porque a menudo quiero X11Forwarding activado para la mayoría de mis servidores, pero luego no quiero ver el X11.... advertencias

$INICIO/.ssh/config

La mayor parte del tiempo, estos mensajes ni siquiera aparecerán. Por lo general, solo están presentes cuando tiene las siguientes entradas en su $HOME/.ssh/config archivo, en la parte superior.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Entonces, es esta configuración la que, en última instancia, está impulsando la generación de esos X11.. mensajes, de nuevo, el método #2 parece ser el más apropiado si desea operar con ForwardX11 yes activado de forma predeterminada, pero luego desactívelo selectivamente para ciertas conexiones desde el ssh perspectiva del cliente.

Relacionado:Linux:¿una buena manera de cifrar y almacenar un buzón de correo y al mismo tiempo poder acceder a él y buscarlo rápidamente?

Seguridad

Por lo general, no se recomienda ejecutar con ForwardX11 yes en 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 yes en tu $HOME/.ssh/config archivo
  2. Utilice ForwardingX11 solo cuando lo necesite a través de ssh -X [email protected]
  3. Si puede, deshabilite X11Forwarding completamente en el servidor por lo que no está permitido

Referencias

  • SSH:The Secure Shell – La guía definitiva – 9.3. X Reenvío

Linux
  1. Ssh:¿restringir un usuario de Ssh/scp/sftp a un directorio?

  2. Linux – ¿Reenvío X11 a través de Ssh?

  3. Cómo resolver un problema de negociación del algoritmo fallido en SSH

  4. Cómo crear un mensaje de bienvenida de inicio de sesión SSH personalizado

  5. Reenvío de puerto ssh motor de cómputo de google

Cómo utilizar el reenvío de puertos SSH

Cómo enumerar inicios de sesión SSH fallidos en Linux

Cómo configurar el reenvío X11 usando SSH en Linux

Cómo configurar el reenvío de puertos dinámicos SSH en Linux

¿Representación OpenGL con reenvío X11?

Uso del reenvío de puertos SSH como herramienta de seguridad en Linux