Pregunta ¿Qué significa "Advertencia: la configuración de reenvío X11 no confiable ha fallado: los datos de la clave xauth no se generaron" significa cuando ssh'ing con -X?


Cuando yo uso ssh -X en mi Mac (con OS X 10.6.7) para conectarme a mi caja de Ubuntu (11.04), recibo la siguiente advertencia:

Advertencia: reenvío X11 no fiable   configuración fallida: datos de clave xauth no   Advertencia generada: No hay datos de xauth;   utilizando datos de autenticación falsos para X11   reenvío

¿Hay algo que pueda hacer para que esta advertencia desaparezca? Si no, ¿puedo ignorarlo con seguridad?

El reenvío X11 parece funcionar bien, aunque veo este mensaje:

Xlib: falta la extensión "RANDR" en   mostrar "localhost: 10.0".

¿Está eso relacionado con la advertencia? (Supongo que no. Si no lo es, presentaré una nueva pregunta sobre eso).


112
2018-05-25 22:41


origen


¿El programa xauth está instalado en el servidor de ubuntu? - slubman
sudo apt-get install xauth me dice "xauth ya es la versión más nueva" - Daryl Spitzer
Cuando inicie sesión en el servidor de ubuntu, ¿cuál es la salida de 'which xauth'? - slubman
De hecho creo que deberías leer esta explicación: mail-archive.com/cygwin-xfree@cygwin.com/msg17927.html … Puedes ignorar esta advertencia - slubman
ocasionalmente, esto puede ser causado por problemas con su archivo ~ / .Xauthority. Si lo elimina, se volverá a crear la próxima vez que intente iniciar sesión. - michael


Respuestas:


¿Alguna razón por la que no quiera usar el indicador -Y en lugar del indicador -X?

En pocas palabras, la diferencia entre -X y -Y es que -Y permite el reenvío X11 de confianza.


125
2018-02-01 22:02



No, simplemente no estaba al tanto de la marca -Y cuando escribí la pregunta. Creo que resultó ser una solución. Cambie su respuesta para que no sea una pregunta (y sería bueno si explicara brevemente la diferencia entre -Y y -C) y la aceptaré. - Daryl Spitzer
¿Hay algún caso en el que no quiera usar -Y en lugar de -X? - Rooster
@ Rooster para sistemas muy antiguos donde -Y no es compatible, diría - Petr
Consejo para la solución de problemas: ejecute "ssh -vv ..." y busque la línea xauth y los mensajes de error. Puedes intentar ejecutar la línea xauth que se muestra directamente. Para el mío, necesitaba que fuera algo como "xauth list: 0" (de confianza) no "xauth -f / tmp / ssh ... list: 0" (no confiable). Que -Y fijo y "ForwardX11Trusted yes" en el host remoto / etc / ssh / ssh_config (o ~ / .ssh / config) también fueron corregidos. - Curtis Yallop
Esta solución también funcionó con Cygwin / X. - linux64kb


Si vienes aquí en 2015: incluso si todo lo demás está configurado correctamente, esto también puede suceder en Mac OS X 10.10 Yosemite, al usar ssh -X y ejecutando una versión de XQuartz <= 2.7.7. La causa principal es que los sockets de pantalla X11 se escriben fuera de la ruta de búsqueda de xauth: problema # 2068 en el rastreador XQuartz.

Edición: un XQuartz fijo ha sido publicado en la nueva página de inicio, xquartz.org, e instalar la última versión desde allí (actualmente 2.7.9) solucionará el problema.


22
2018-05-13 15:09



¡Gracias! tuve ni idea que el XQuartz I sólo descargado desde la parte superior de la página de XQuartz no es realmente la última versión. - craigds
Vale la pena señalar que brew install xquartz Actualmente instala la versión 2.7.7 caducada. - Martin Cleaver
brew install Caskroom/cask/xquartz debería conseguirte la última XQuartz con HomeBrew - Nick
O mas corto brew cask install xquartz. - Franklin Yu


Si recibe el mismo mensaje incluso al usar -Y, la xauth Puede que falte un programa en el servidor. En sistemas similares a Debian, necesita la xauth paquete. En sistemas similares a RedHat, necesita el xorg-x11-xauth paquete.


14
2017-07-17 08:35





"No confiable" en este contexto significa que no confía en la conexión. SSH utilizará medidas de seguridad adicionales para intentar que el reenvío X11 sea más seguro. "De confianza" significa que está completamente seguro de que no en el host remoto tendrá acceso a sus datos de Xauth y los usará para controlar sus pulsaciones de teclado, por ejemplo.

Esta terminología en realidad me confundió durante años. Pensé que las conexiones "de confianza" eran más seguras. Pero en realidad es una opción que se supone que debes usar en situaciones en las que la conexión ES confiable y quieres ejecutar cosas sin que se interpongan medidas de seguridad adicionales en tu camino. "No confiable" es el que lo hace (de alguna manera) más seguro tratar con un host remoto no confiable.

Una conexión "No confiable" intenta limitar lo que podría hacerte un sombrero negro al activar la extensión de seguridad X11 y desactivar otras extensiones que (con suerte) no necesitas. Probablemente esta sea la razón por la que RandR está deshabilitado con -X. ¿Necesita poder girar su pantalla X desde el host remoto?

También es importante tener en cuenta que el reenvío X11 "no confiable" se desactiva después de un cierto tiempo para evitar que lo dejes accidentalmente. Los nuevos intentos de abrir ventanas solo fallarán después de eso. Eso me mordió varias veces antes de leer suficientes documentos para entender lo que estaba sucediendo.


11
2018-02-17 17:36





No tengo una configuración que pueda mostrar este comportamiento, por lo que esta es una foto en la oscuridad:

La advertencia podría ser suprimida si establece ForwardX11Trusted a "no" Para los anfitriones que dan esta advertencia. Puede colocar esto en cualquiera ~/.ssh/config o /etc/ssh/ssh_config, y puede hacer que la opción sea específica para un host en particular al incluir Host <hostname> en la línea de arriba. la <hostname> el componente coincide con lo que escribe en la línea de comando (no el nombre de host resuelto), y puede incluir comodines.


8
2018-06-13 20:03



Uno puede usar ssh -Y para hacer un reenvío X11 de confianza, pero ¿cómo se puede arreglar el que no es de confianza? - Pavel Šimerda
Obtuve el mismo error en Redhat y ahora puedo resolverlo editando el archivo de configuración /etc/ssh/ssh_config en el lado del cliente. Gracias - Gangadhar Jannu


Si instala xauth no funciona bien, un caso particularmente molesto podría estar dañado .Xauthority expediente. Este caso particular permitió a algunos clientes X trabajar, pero no a otros con una mayor tendencia a fallar con pantallas más nuevas. Eliminando y recreando el .Xauthority archivo puede resolver ese problema.


5
2017-08-01 17:43





Descartar problemas del lado del servidor

Primero, debes descartar cualquier problema del lado del servidor. Eres capaz de ssh -X de cualquier otro host con éxito? Hace ssh -Y trabajar mientras ssh -X no? En cualquier caso, suponga que ssh + X11 está configurado correctamente en su servidor y pase a la siguiente sección.

Si no está en posición de verificarlo (digamos, pero tiene su única computadora portátil con X11, puede) ssh desde el servidor a sí mismo usando una sesión falsa:

  1. export DISPLAY=:44 # (Shell Bourne) o
    setenv DISPLAY :44 # (csh / tcsh)
  2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234  # Bogus cookie solo para esta prueba
  3. ssh -X localhost env |grep DISPLAY

Resultado esperado: debe haber una variable DISPLAY configurada en el extremo remoto de la sesión ssh-to-self. Si no obtiene ningún resultado, es probable que su servidor esté mal configurado (por ejemplo, las bibliotecas X11 y / o la xauth El comando podría faltar; o la configuración sshd podría configurarse para denegar el acceso a X11)

En Mac: compruebe que Xquartz está actualizado

Según La respuesta de will angley

Examinar ssh -vv -X salida

El mensaje de error que cita es un síntoma que puede tener muchas causas. Intente de nuevo con ssh -X -vv servidor remoto, lo que debería darle pistas adicionales sobre por qué falló la configuración del túnel X11.

¿Ves aparecer el siguiente mensaje?

debug1: No hay programa xauth.
Si es así,

  1. Tome nota de dónde está en su sistema cliente, el xauth el comando reside:
    cual xauth
  2. Agregue lo siguiente al final de su ~ / .ssh / config (y agregue un comentario para recordarle que debe mantenerlo en el futuro):
    Anfitrión *
        XAuthLocation / opt / X11 / bin / xauth
    
    Ajuste este camino según los hallazgos del paso 1 - Créditos a Jan-Willem Arnold

5
2017-08-18 16:34





TENER CUIDADO (Cansado de leer respuestas incompletas que conducen a una falla de seguridad)

1 / usar ssh -Y significa aquí tener información falsa de xauth que es mala!

2 / ssh -X debería funcionar ya que XQuartz, una vez habilitado, usa xauth. El único problema es que ssh está buscando xauth en / usr / X11R6 / bin y en macos con XQuartz está en / opt / X11 / bin

Resolución segura:

1 / Habilitar la primera opción en Seguridad pestaña de preferencias (cmd-,) que permite conexiones autenticadas

2 / agregar

XAuthLocation /opt/X11/bin/xauth

en $ HOME / .ssh / config

3 / ssh -X you_server trabaja de manera segura


4
2018-01-31 13:16





Ya tenía instalado el último XQuartz 2.7.11, pero creo que también he actualizado el sistema operativo varias veces desde entonces. Reinstalé XQuartz 2.7.11, y ahora está funcionando bien.


-1
2018-04-01 12:52





xauth agrega `hostname` / unix: 10 MIT-MAGIC-COOKIE-1` openssl rand -hex 16`


-3
2018-06-11 04:27



No entiendo - Pierre.Vriens