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

134

Cuando uso ssh -Xen mi Mac (ejecutando OS X 10.6.7) para conectarme a mi cuadro de Ubuntu (11.04), recibo la siguiente advertencia:

Advertencia: la configuración de reenvío X11 no confiable falló: no se generaron los datos de la clave xauth Advertencia: No hay datos xauth; utilizando datos de autenticación falsos para el reenvío X11.

¿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 la pantalla "localhost: 10.0".

¿Está relacionado con la advertencia? (Supongo que no. Si no es así, presentaré una nueva pregunta al respecto).

ssh  x11forwarding  warning 
— Daryl Spitzer
fuente
1
¿Está instalado el programa xauth en el servidor ubuntu?
— Slubman
sudo apt-get install xauthme dice "xauth ya es la versión más nueva"
— Daryl Spitzer
Al iniciar sesión en el servidor ubuntu, ¿cuál es el resultado 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
2
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:

145

¿Alguna razón por la que no desea usar la bandera -Y en lugar de la bandera -X?

En pocas palabras, la diferencia entre -X e -Y es que -Y permite el reenvío X11 confiable.

— usuario5336
fuente
44
No, simplemente no estaba al tanto de la bandera -Y cuando escribí la pregunta. Creo que eso 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 quieras usar -Y en lugar de -X?
— Gallo
@Rooster para sistemas muy antiguos donde -Y no es compatible, diría
— Petr
Consejo para la resolución de problemas: Ejecute "ssh -vv ..." y busque la línea xauth y cualquier mensaje de error. Puede intentar ejecutar la línea xauth que muestra directamente. Para mí, necesitaba que fuera algo así como "xauth list: 0" (confiable) no "xauth -f / tmp / ssh ... list: 0" (no confiable). Que -Y solucionó y "ForwardX11Trusted yes" en el host remoto / etc / ssh / ssh_config (o ~ / .ssh / config) también reparó.
— Curtis Yallop
Esta solución también funcionó con Cygwin / X.
— linux64kb
25

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

Editar: desde entonces se ha lanzado un XQuartz fijo en la nueva página de inicio, xquartz.org , y la instalación de la última versión desde allí (actualmente 2.7.9) solucionará el problema.

— Will Angley
fuente
1
¡Gracias! No tenía idea de que el XQuartz que acabo de descargar de la parte superior de la página de XQuartz no es en realidad la última versión.
— Craigds
Vale la pena señalar que brew install xquartzactualmente instala la versión desactualizada 2.7.7.
— Martin Cleaver
brew install Caskroom/cask/xquartzdebería ofrecerte el último XQuartz con HomeBrew
— Nick
O más corto brew cask install xquartz.
— Franklin Yu
17

Si recibe el mismo mensaje incluso cuando lo usa -Y, el xauthprograma podría faltar en el servidor. En sistemas similares a Debian, necesita el xauthpaquete. En sistemas similares a RedHat, necesita el xorg-x11-xauthpaquete.

— Flup
fuente
15

"No confiable" en este contexto significa que no confía en la conexión. SSH utilizará medidas de seguridad adicionales para tratar de hacer que el reenvío X11 sea más seguro. "Confiable" significa que está completamente seguro de que ningún encendido del host remoto tendrá acceso a sus datos de Xauth y, por ejemplo, lo usará para controlar sus pulsaciones de teclas.

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

Una conexión "no confiable" intenta limitar lo que un sombrero negro podría hacerle al activar la extensión de seguridad X11 y desactivar otras extensiones que (con suerte) no necesita. Esta es probablemente 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 apaga después de un cierto tiempo para evitar que lo deje accidentalmente. Los nuevos intentos de abrir ventanas simplemente fallarán después de eso. Eso me mordió varias veces antes de leer suficientes documentos para entender lo que estaba sucediendo.

— tetsujin
fuente
9

No tengo una configuración que pueda exhibir este comportamiento, así que esta es una toma en la oscuridad:

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

— Michael Lowman
fuente
Se puede usar ssh -Ypara hacer reenvío X11 confiable, pero ¿cómo se puede arreglar el no confiable?
— Pavel Šimerda
Recibí el mismo error en Redhat y ahora puedo resolverlo editando el archivo de configuración /etc/ssh/ssh_configen el lado del cliente. Gracias
— Gangadhar Jannu
7

CUIDADO (cansado de leer respuestas incompletas que conducen a fallas de seguridad)

1 / usar ssh -Y significa que aquí tenemos 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

Solución segura:

1 / Habilite la primera opción en la pestaña Seguridad de preferencias (Cmd-,) que habilita conexiones autenticadas

2 / agregar

XAuthLocation /opt/X11/bin/xauth

en $ HOME / .ssh / config

3 / ssh -X you_servertrabaja de manera segura

— Koko
fuente
6

Si la instalación xauthno funciona correctamente, un caso particularmente molesto podría ser un .Xauthorityarchivo dañado . Este caso particular permitió que algunos clientes X funcionaran, pero no otros con una mayor tendencia a fallar con pantallas más nuevas. Eliminar y volver a crear el .Xauthorityarchivo puede resolver ese problema.

— hildred
fuente
6

Descartar problemas del lado del servidor

Primero, debe descartar cualquier problema del lado del servidor. ¿Eres capaz ssh -Xde cualquier otro host con éxito? ¿ ssh -YFunciona mientras ssh -Xque 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 condiciones de verificar eso (por ejemplo, solo tiene su computadora portátil con X11), puede sshhacerlo desde el servidor a sí mismo mediante una sesión falsa:

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

Resultado esperado: debe haber una variable DISPLAY establecida 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 el xauthcomando podrían faltar; o la configuración sshd podría configurarse para denegar el acceso X11)

En Mac: compruebe que Xquartz esté actualizado

Según la respuesta de Will Angley

Examinar ssh -vv -Xsalida

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

¿Ves aparecer el siguiente mensaje?

debug1: sin programa xauth.
Si es así,

  1. Tome nota de en qué parte de su sistema cliente xauthreside el comando:
    cual xauth
  2. Agregue lo siguiente al final de su ~ / .ssh / config (y agregue un comentario para recordar que debe mantenerlo allí en el futuro):
    Anfitrión *
    XAuthLocation / opt / X11 / bin / xauth
    Ajuste esta ruta según los hallazgos del paso 1 - Créditos a Jan-Willem Arnold
— DomQ
fuente
3

Como ya se explicó anteriormente, lo siguiente funcionó para mí:

Edite ~ / .ssh / config para agregar las líneas

Host *
    XAuthLocation /opt/X11/bin/xauth

y ahora funciona ssh -X hostname (XQuartz 2.7.11, macOS 10.4 Mojave)

— Shepster
fuente
0

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 funciona bien.

— Ulmo
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.