SSH-reenviado X11 pantalla de Linux a Mac perdido después de algún time

Tengo un nuevo y molesto problema con ssh reenvío de mi connection X11 al iniciar session desde un Mac (10.7.2) a Linux (Ubuntu 8.04). No tengo problemas para usar ssh -X para iniciar session en la máquina remota y iniciar una aplicación basada en X11 desde esa shell.

Lo que recientemente ha comenzado a suceder es que las invocaciones adicionales de las aplicaciones X11 de esa misma shell, después de un time (en el order de las horas), no pueden iniciarse porque la pantalla reenviada se está bloqueando (supongo). Cuando bash iniciar xterm, por ejemplo, recibo el post habitual acerca de una configuration de DISPLAY incorrecta, como por ejemplo:

xterm Xt error: No se puede abrir la pantalla: localhost: 10.0

Pero la aplicación X11 que comencé justo cuando inicié la session sigue funcionando bien, usando esa misma pantalla (localhost: 10.0), sólo que se inició anteriormente.

Activé el logging detallado en sshd_config y lo veo en el file /var/log/auth.log en respuesta al bash fallido de inicio de xterm:

sshd [22104]: canal 8: abierto error: administrativamente prohibido: abierto fallido

Si ssh -X al server de nuevo, a partir de un nuevo shell y se asigna una nueva pantalla (localhost: 11.0), el mismo process se repite: las aplicaciones X11 se inició temprano en funcionamiento muy bien siempre y cuando los mantenga abiertos (días ), pero después de unas horas no puedo iniciar ninguna nueva desde ese shell.

Particularidades: Servidor sshd OpenSSH que se ejecuta en Ubuntu 8.04, la pantalla se reenvía a un Mac ejecutando Lion (10.7.2) con el server Apple X pnetworkingeterminado. Los sistemas están conectados en una LAN Ethernet con un solo interruptor entre ellos. Ninguna de las dos máquinas ejecuta un firewall. Hasta hace poco (hace unos días) esta configuration funcionó perfectamente así que estoy desconcertado en cuanto a dónde mirar a continuación. No soy un experto en X11 o SSH, pero tengo una buena experiencia con UNIX / Linux. Nada obvio ha cambiado en la configuration de cliente o server, aunque he intentado cambiar algunas opciones para intentar depurar esto, como establecer TCPKeepAlive de sshd_config a no, y establecer "host + localhost" (se puede decir que he estado en Google).

Cuando se inicia una session desde un orderador portátil Linux 11.10 al mismo host remoto en la misma networking y el mismo conmutador, este problema no ocurre: un xterm puede ser invocado satisfactoriamente horas después desde el mismo shell de inicio de session ssh mientras falla el mismo experimento desde el Mac. probado esta mañana para estar seguro), por lo que parece ser un problema específico de Mac.

Con "LogLevel DEBUG3" establecido en la máquina remota (server sshd) y ningún cambio realizado en las conexiones de cliente por mí, /var/log/auth.log muestra un ligero cambio en los informes de estado de la connection durante la noche, que es el número de puerto utilizado por la exitosa session ssh de la máquina Linux (creo), connection # 7 a continuación:

sshd [20173]: debug3: canal 7: estado: Las siguientes conexiones están abiertas: \ r \ n # 0 server session (t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1) \ r \ n # 3 X11 desde el puerto 127.0.0.1 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Conexión X11 desde el puerto 127.0.0.1 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 Conexión X11 desde el puerto 127.0.0.1 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 Conexión X11 desde el puerto 127.0.0.1 57567 (t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1) \ r \ n # 7 Conexión X11 desde el puerto 127.0.0.1 59007

En este informe, todo es igual entre los informes de estado, excepto el número de puerto utilizado por la connection # 7 que creo que es el cliente de Linux – el único que todavía mantiene una connection de pantalla. Sigue aumentando con el time, a juzgar por una secuencia de estos informes durante la noche.

Gracias por cualquier ayuda,

-Micro

2 Solutions collect form web for “SSH-reenviado X11 pantalla de Linux a Mac perdido después de algún time”

Las sesiones ssh comenzaron después de cambiar el / etc / ssh_config del cliente Mac para include la línea:

ForwardX11Timeout 596h

están trabajando bien y han estado todo el día. A estas alturas todos ellos se habrían negado a comenzar nuevos xterms. Así que creo que esta es la respuesta, y por suerte una solución sencilla, pero el time de espera todavía sucederá 3-1 / 2 semanas a partir de ahora.

man ssh_config

ForwardX11Trusted

Si esta opción está configurada como "sí", los clientes X11 remotos tendrán acceso completo a la pantalla original X11. Si esta opción está configurada como "no", los clientes X11 remotos se considerarán no fiables y se evitará el robo o manipulación de datos pertenecientes a clientes de confianza X11. Además, el token xauth (1) utilizado para la session se configurará para que expire después de 20 minutos. A los clientes remotos se les negará el acceso después de este time. El valor pnetworkingeterminado es "no" Consulte la especificación de extensión X11 SECURITY para get detalles completos sobre las restricciones impuestas a los clientes no fiables.

  • Cloud Linux con aceleración OpenGL?
  • Restringir la configuration de xscreensaver que cambia el usuario
  • Centos 6 problemas de dependencia x2go al intentar ejecutar yum actualización
  • ¿Cómo configurar una GUI de escritorio con una instancia de Amazon EC2?
  • ffmpeg con x11grab resultados en pantalla en negro en la reproducción vlc
  • ¿Cómo usar Xorg para KVM virtual?
  • Problemas al abrir Gedit con X11 en la nueva installation de Ubuntu
  • abrir terminal a través de ssh ejecutar firefox -> display not found
  • Vincular Xvfb en localhost en lugar de *
  • ¿Cómo puedo eliminar completamente X-Windows de Fedora?
  • Tiempo de espera en el locking /.Xauthority
  • ¿Cómo obtengo un monitor en el paisaje y un monitor en modo retrato en Ubuntu 9.04?
  • Compartir un server de escritorio linux para varios usuarios: escritorio remoto o virtualización?
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.