Tengo un problema nuevo y molesto con ssh reenviando mi conexión X11 al iniciar sesión desde una Mac (10.7.2) a Linux (Ubuntu 8.04). No tengo problemas para usar ssh -X para iniciar sesión en la máquina remota e iniciar una aplicación basada en X11 desde ese shell.
Lo que recientemente comenzó a suceder es que invocaciones adicionales de aplicaciones X11 desde ese mismo shell, después de un tiempo (del orden de horas), no pueden iniciarse porque la pantalla reenviada está bloqueada (supongo). Cuando intento iniciar xterm, por ejemplo, recibo el mensaje habitual sobre una configuración de PANTALLA incorrecta, como:
xterm Error Xt: no se puede abrir la pantalla: localhost: 10.0
Pero la aplicación X11 que comencé justo cuando inicié sesión todavía funciona bien, usando exactamente la misma pantalla (localhost: 10.0), solo que se inició antes.
Encendí el registro detallado en sshd_config y veo esto en el archivo /var/log/auth.log en respuesta al intento fallido de inicio de xterm:
sshd [22104]: canal 8: error de apertura: prohibido administrativamente: error de apertura
Si ssh -X al servidor nuevamente, iniciando un nuevo shell y obteniendo una nueva pantalla (localhost: 11.0), se repite el mismo proceso: las aplicaciones X11 comenzaron temprano y se ejecutan bien durante el tiempo que las mantengo abiertas (días ), pero después de unas horas no puedo iniciar ninguna nueva desde ese shell.
Detalles: servidor OpenSSH sshd que se ejecuta en Ubuntu 8.04, pantalla reenviada a una Mac con Lion (10.7.2) con el servidor Apple X predeterminado. Los sistemas están conectados en una LAN Ethernet con un solo conmutador entre ellos. Ninguna de las máquinas está ejecutando un firewall. Hasta hace poco (hace unos días), esta configuración funcionaba perfectamente, así que estoy desconcertado sobre dónde mirar a continuación. De ninguna manera soy un experto en X11 o SSH, pero tengo una buena experiencia en UNIX / Linux. Nada obvio ha cambiado en la configuración del cliente o del servidor, aunque he intentado cambiar algunas opciones para intentar depurar esto, como establecer TCPKeepAlive de sshd_config en no, y establecer "host + localhost" (se puede decir que he estado buscando en Google).
Al iniciar sesión desde una computadora portátil Linux 11.10 en el mismo host remoto a través de la misma red y conmutador, este problema no ocurre: se puede invocar un xterm con éxito horas después desde el mismo shell de inicio de sesión ssh mientras falla el mismo experimento de Mac ( probado esta mañana para estar seguro), por lo que parece ser un problema específico de Mac.
Con "LogLevel DEBUG3" configurado en la máquina remota (servidor sshd) y ningún cambio realizado en las conexiones del cliente por mí, /var/log/auth.log muestra un ligero cambio en los informes de estado de conexión durante la noche, que es el número de puerto utilizado por la exitosa sesión ssh de la máquina Linux (creo), conexión # 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 Conexión X11 desde 127.0.0.1 puerto 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Conexión X11 desde 127.0.0.1 puerto 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 conexión X11 desde 127.0.0.1 puerto 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 conexión X11 desde 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 conexión n. ° 7, que creo que es el cliente Linux, el único que aún mantiene una conexión de pantalla. Continúa incrementándose con el tiempo, a juzgar por una secuencia de estos informes durante la noche.
Gracias por cualquier ayuda,
-Miguel
codeObtuve esto: rechazó la conexión X11 después de que ForwardX11Timeout expiró ForwardX11Timeout es una opción en el cliente ssh de Mac que limita el reenvío desde una conexión no confiable. Potencialmente, usar -Y en lugar de -X funcionaría. ForwardX11Timeout no está documentado en la página de manual ssh de Lion. Su valor predeterminado parece ser de 20 minutos. Es posible configurarlo más alto en ssh_config, pero el servidor Lion's X se bloquea si se establece en> 596 horas ... que, en milisegundos, se desborda 31 bits. Arrgh Espero que esto lo arregle.Respuestas:
Las sesiones ssh comenzaron después de cambiar el / etc / ssh_config del cliente Mac para incluir la línea:
Todos funcionan bien y han estado todo el día. A estas alturas, todos se habrían negado a comenzar nuevas xterms. Así que creo que esta es la respuesta, y afortunadamente una solución simple, pero el tiempo de espera seguirá ocurriendo dentro de tres semanas y media.
fuente
man ssh_configfuente
Para agregar a "respondió el 7 de enero de 12 a las 0:11 mklein9 28129" "Las sesiones de ssh comenzaron después de cambiar el / etc / ssh_config del cliente Mac para incluir la línea:
... pero el tiempo de espera seguirá sucediendo dentro de tres semanas y media ".
Aparentemente puede usar 0 y esto establece el tiempo de espera al infinito (siempre que la conexión esté activada).
...
fuente