Tengo una puerta de enlace para acceder por ssh desde la mala red mundial. No hay problema, me sale:
remote ~$ ssh -X ingo@gateway
Debian GNU/Linux 10 (buster)
0:ingo@gateway ~$
Ahora administro mis otros hosts, por ejemplo el servidor de archivos:
0:ingo@gateway ~$ ssh -X ingo@fileserver
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Debian GNU/Linux 10 (buster)
0:ingo@fileserver~$
Recibo esa advertencia.
Pero si hago ssh desde mi host de administración en la red local directamente al servidor de archivos, funciona sin la Advertencia. He verificado esto con otros inicios de sesión. Solo recibo la Advertencia cuando ssh de un ssh.
¿Por qué tengo
Advertencia: falló la configuración de reenvío X11 que no es de confianza: no se generaron datos de clave xauth
¿Solo en inicios de sesión ssh anidados?
¿Cómo puedo evitar esta advertencia y puedo utilizar con éxito el reenvío X11 que no es de confianza, más seguro?
Y no, no quiero usar la -Yopción menos segura en ssh para el reenvío X11 confiable en lugar de la -Xopción usada.
Respuesta1
Cuando su única conexión a un servidor X11 esno confiable, no puedes reenviarlo más.
El reenvío X11 que no es de confianza funciona cuando el cliente ssh se conecta a la pantalla local y usa el xauth generate $DISPLAY . untrustedcomando para generar unno confiableclave/cookie.
Pero para eso, el xauthcomando necesita que la SECURITYextensión esté presente en la pantalla, que, como la mayoría de las extensiones, está oculta y/o deshabilitada cuando un cliente como xauthse autenticó con una cookie que no es de confianza.
Puedes comprobarlo fácilmente con:
$ touch /tmp/junk1 /tmp/junk2
$ chmod 600 /tmp/junk*
$ xauth -f /tmp/junk1 generate :0 . untrusted
$ XAUTHORITY=/tmp/junk1 oclock
# get a square oclock because the Shape extension is disabled
$ XAUTHORITY=/tmp/junk1 xdpyinfo | grep -A2 extensions
number of extensions: 2
BIG-REQUESTS
XC-MISC
# vs 28 or so on a trusted display
$ XAUTHORITY=/tmp/junk1 xauth -f /tmp/junk2 generate :0 . untrusted
xauth: (argv):1: couldn't query Security extension on display ":0"
El último paso provocará la advertencia que recibirá en ssh.
Por lo tanto, se debe confiar al menos en el primer reenvío X11; de lo contrario, no funcionaría.
Alternativamente, deberías "saltar" a través del host intermedio, que realizará un único reenvío X11:
ssh -X -o ForwardX11Trusted=no -J ingo@gateway ingo@fileserver
Tenga en cuenta que es explícito ForwardX11Trusted=no, porque en Debian las opciones -Xy -Yson equivalentes y obtendrá unconfiableReenvío X11 de forma predeterminada, sin importar cuál estés usando.