Eu tenho um problema novo e irritante com o ssh encaminhando minha conexão X11 ao fazer o login de um Mac (10.7.2) para Linux (Ubuntu 8.04). Não tenho problemas para usar o ssh -X para efetuar login na máquina remota e iniciar um aplicativo baseado no X11 a partir desse shell.
O que começou recentemente a acontecer é que invocações adicionais de aplicativos X11 desse mesmo shell, depois de um tempo (na ordem de horas), não podem ser iniciadas porque a exibição encaminhada está sendo bloqueada (presumo). Ao tentar iniciar o xterm, por exemplo, recebo a mensagem usual sobre uma configuração de DISPLAY ruim, como:
xterm Xt error: Não é possível abrir a tela: localhost: 10.0
Mas o aplicativo X11 que iniciei quando fiz o login ainda está funcionando perfeitamente, usando exatamente a mesma exibição (localhost: 10.0), apenas que foi iniciado anteriormente.
Ativei o log detalhado no sshd_config e vejo isso no arquivo /var/log/auth.log em resposta à tentativa falha de inicialização do xterm:
sshd [22104]: canal 8: falha na abertura: proibido administrativamente: falha na abertura
Se eu ssh -X no servidor novamente, iniciando um novo shell e recebendo uma nova exibição (localhost: 11.0), o mesmo processo se repete: os aplicativos X11 iniciaram cedo, rodando muito bem desde que eu os mantenha abertos (dias ), mas depois de algumas horas não consigo iniciar novos a partir desse shell.
Detalhes: O servidor OpenSSH sshd em execução no Ubuntu 8.04, é encaminhado para um Mac executando o Lion (10.7.2) com o servidor Apple X padrão. Os sistemas estão conectados em uma LAN Ethernet com um único switch entre eles. Nenhuma máquina está executando um firewall. Até recentemente (alguns dias atrás), essa configuração funcionava perfeitamente, por isso estou confuso quanto ao local a seguir. Não sou especialista em X11 ou SSH, mas tenho uma boa experiência em UNIX / Linux. Nada óbvio mudou na configuração do cliente ou do servidor, embora eu tenha tentado alterar algumas opções para tentar depurar isso, como configurar TCPKeepAlive do sshd_config como no e definir "host + localhost" (você pode ver que estou pesquisando no Google).
Ao fazer logon de um laptop Linux 11.10 no mesmo host remoto na mesma rede e switch, esse problema não ocorre - um xterm pode ser chamado com sucesso horas depois no mesmo shell de login ssh enquanto o mesmo experimento no Mac falha ( testado esta manhã para ter certeza), então parece ser um problema específico do Mac.
Com o "LogLevel DEBUG3" definido na máquina remota (servidor sshd) e nenhuma alteração feita nas conexões do cliente por mim, /var/log/auth.log mostra uma pequena alteração nos relatórios de status da conexão durante a noite, que é o número da porta usada pela sessão ssh bem-sucedida da máquina Linux (eu acho), conexão nº 7 abaixo:
sshd [20173]: debug3: canal 7: status: As seguintes conexões estão abertas: \ r \ n # 0 sessão do servidor (t4 r0 i0 / 0 o0 / 0 fd 14/13 cfd -1) \ r \ n # 3 Conexão X11 da porta 127.0.0.1 57564 (t4 r1 i0 / 0 o0 / 0 fd 16/16 cfd -1) \ r \ n # 4 Conexão X11 da porta 127.0.0.1 57565 (t4 r2 i0 / 0 o0 / 0 fd 17 / 17 cfd -1) \ r \ n # 5 conexão X11 da porta 127.0.0.1 57566 (t4 r3 i0 / 0 o0 / 0 fd 18/18 cfd -1) \ r \ n # 6 conexão X11 da porta 127.0.0.1 57567 (t4 r4 i0 / 0 o0 / 0 fd 19/19 cfd -1) \ r \ n # 7 conexão X11 da porta 127.0.0.1 porta 59007
Neste relatório, tudo é igual entre os relatórios de status, exceto o número da porta usada pela conexão nº 7, que acredito ser o cliente Linux - o único que ainda mantém uma conexão de vídeo. Ele continua a aumentar com o tempo, a julgar por uma sequência desses relatórios da noite para o dia.
Obrigado por qualquer ajuda,
-Mike
codeConexão X11 rejeitada após o término do ForwardX11Timeout O ForwardX11Timeout é uma opção no cliente ssh do Mac que limita o encaminhamento de uma conexão não confiável. Potencialmente, usar -Y em vez de -X funcionaria. O ForwardX11Timeout não está documentado na página do manual do ssh do Lion. Seu padrão parece ser 20 minutos. É possível configurá-lo mais alto em ssh_config, mas o servidor X do Lion trava se definido como> 596 horas ... o que, em milissegundos, excede 31 bits. Arrgh. Espero que isso conserte.