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.

  • Instalar x windows en Centos no funciona
  • Restringir la configuration de xscreensaver que cambia el usuario
  • ¿Cómo averiguar el terminal virtual Linux activo mientras está conectado a través de ssh?
  • ¿Cómo instalo una fuente en Linux para que sea utilizable por xterm?
  • ¿Es posible ejecutar X en una console de service ESX?
  • Tiempo de espera en el locking /.Xauthority
  • ¿Cuál es la mejor manera, si es posible, para mantener una session remota de X que sobrevive interrupciones de la networking, reinicios etc
  • Cloud Linux con aceleración OpenGL?
  • X11 reenvío de OSX a Linux
  • ¿Cómo inicio una aplicación X en un server remoto a través de ssh?
  • X sobre SSH a server Ubuntu
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.