ssh El reenvío de X11 no funcionará

Question

He intentado hacer que el reenvío de puertos X11 funcione desde mi computadora portátil. No puedo entender por qué no va a funcionar.

me sale este mensaje cuando trato de ejecutar xterm:

X11 connection rejected because of wrong authentication. 
xterm Xt error: Can't open display: localhost:10.0 

No sé si esto está relacionado o no, pero cuando me conecto, consigo este mensaje:

/usr/bin/xauth: timeout in locking authority file /home/sphillips/.Xauthority 

Me he preguntado si el problema es que mi usuario local en mi computadora portátil es skp y el nombre de usuario en este servidor es sphillips. He podido reenviar X11 para que funcione con mis otras computadoras que usan el mismo inicio de sesión skp.

Además, el reenvío de puertos X11 funciona desde una máquina Windows utilizando Xming y Putty en el mismo servidor. Tengo que configurar manualmente la variable DISPLAY en la dirección IP y mostrar 0.0, pero funciona.

He ejecutado un xhost + en mi máquina con el intento de intentar eludir cualquier problema de seguridad. Eso todavía no funcionó.

En el servidor, puedo comprobar la configuración:

$ sudo grep X11Forwarding /etc/ssh/sshd_config 
#X11Forwarding no 
X11Forwarding yes 
# X11Forwarding no 

Y en mi máquina así:

$ sudo grep X11Forwarding /etc/ssh/sshd_config 
[sudo] password for skp: 
#X11Forwarding no 
X11Forwarding yes 
# X11Forwarding no 

Mi servidor es RedHat Enterprise Linux 6 y mi portátil es Fedora 15.

¿Alguien me puede dar alguna idea sobre las cosas para intentar que el reenvío SSH X11 funcione desde mi computadora portátil?

Answer 1

Tengo el mismo problema en un contenedor Debian OpenVZ y el problema parece provenir de mi archivo/etc/hosts donde "localhost" se vio afectado a la dirección IP de LAN, no a 127.0.0.1.

Antes:

192.168.0.15 dagi dagi.domain.net localhost localhost.localdomain 

Después:

192.168.0.15 dagi dagi.domain.net 
127.0.0.1  localhost localhost.localdomain 

Después de eso, tanto ssh -X y ssh -Y trabajó como un encanto sin ni siquiera reiniciar sshd.

Answer 2

¡Finalmente encontré la respuesta (al menos para mi situación)! El problema fue SELinux. Apagué SELinux, y funcionó sin problemas.

Si está interesado en todos los detalles sangrientos, puede leer al respecto en my blog, pero permítame detallar los hechos pertinentes aquí ...

en la máquina remota, solía dmesg para ver los mensajes de registro:

dmesg | tail 

he encontrado una serie de mensajes de la siguiente manera:

type=1400 audit(1332520527.110:51337): avc: denied { read } for pid=25240 comm="sshd" name="authorized_keys" dev=dm-5 ino=167 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file 

Puede comprobar el estado de SELinux con este comando:

$ sestatus 
SELinux status: enabled 
SELinuxfs mount: /selinux 
Current mode: permissive 
Mode from config file: permissive 
Policy version: 24 
Policy from config file: targeted 

puede convertirlo a modo permisivo con este comando:

setenforce 0 

Para obtener más información sobre SELinux, encontré Red Hat's guide helpful. Además, para otros problemas de SSH, encontré David's blog útil para que logge la tarea de ayudar.

Para mí, después de eso, mi reenvío X11 comenzó a funcionar sin problemas.

SELinux impedía muchas otras cosas diferentes. No pudo crear los archivos necesarios para que la autenticación de claves funcione. También lo encontré bloqueando que ssh-keygen cree claves en el directorio de inicio.

Answer 3

sudo grep X11Forwarding /etc/ssh/sshd_config 

X11Forwarding yes 
#sestatus 
SELinux status: enabled 
SELinuxfs mount: /selinux 
Current mode: permissive 
Mode from config file: permissive 
Policy version: 24 
Policy from config file: targeted 
#You can turn it to permissive mode with this command: 
#setenforce 0 

Answer 4

Aparte de la respuesta de @Chl s anterior, también tenía un archivo corrupto ~/.Xauthority.

Por alguna razón, fue propiedad de root incluso en mi directorio personal. Entonces tuve que marcar sudo -s y luego lo borré.

vuelve a crear con touch ~/.Xauthority

Después de que el reenvío de X trabajó para mí, bajo Ubuntu 14.04.

Answer 5

Me topé con esto también. Pero en mi caso fue porque eliminé el soporte de IPv6 hace algunos días. Luego me topé con this thread explicando cómo asegurarme de que sshd use solo IPv4.

Esta es la forma en que lo hice, añadir lo siguiente:

AddressFamily inet 

a su ssh_config-archivo (en Ubuntu/etc/ssh/sshd_config) y hacer que sshd recargar su configuración (kill pid -SIGHUP-de- sshd).