Eu tenho um problema novo e problemático com o ssh encaminhando minha conexão X11 ao efetuar login de um Mac (10.7.2) para o Linux (Ubuntu 8.04). Não tenho problemas em usar o ssh -X para efetuar login na máquina remota e iniciar um aplicativo baseado em 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 das 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 ruim de DISPLAY, como:
xterm Xt error: Can't open display: localhost:10.0
Mas o aplicativo X11 que iniciei quando fiz o login ainda está rodando bem, usando exatamente o mesmo display (localhost: 10.0), apenas que foi iniciado anteriormente.
Eu ativei a criação de log detalhado no sshd_config e vejo isso no arquivo /var/log/auth.log em resposta à falha na tentativa de inicialização do xterm:
sshd[22104]: channel 8: open failed: administratively prohibited: open failed
Se eu ssh -X para o servidor novamente, iniciando um novo shell e recebendo um novo display (localhost: 11.0), o mesmo processo se repete: os aplicativos do X11 iniciam muito cedo, desde que eu os mantenha aberto (dias), mas depois de algumas horas não consigo iniciar nenhum novo a partir desse shell.
Detalhes: Servidor sshd OpenSSH sendo executado no Ubuntu 8.04, exibição encaminhada 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 das máquinas está executando um firewall. Até recentemente (alguns dias atrás) esta configuração funcionou perfeitamente, então estou confuso quanto a onde procurar a seguir. Não sou de forma alguma um 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 o TCPKeepAlive do sshd_config como não e configurar "host + localhost" (você pode dizer que estive pesquisando). / p>
Ao efetuar logon de um laptop Linux 11.10 no mesmo host remoto sobre a mesma rede e comutador, esse problema não ocorre - um xterm pode ser chamado com êxito horas depois do mesmo shell de login ssh enquanto o mesmo experimento do Mac falha (testado esta manhã para ter certeza), por isso 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 é a número de porta usado pela sessão ssh bem-sucedida da máquina Linux (eu acho), conexão 7 abaixo:
sshd[20173]: debug3: channel 7: status: The following connections are open:\r\n #0 server-session (t4 r0 i0/0 o0/0 fd 14/13 cfd -1)\r\n #3 X11 connection from 127.0.0.1 port 57564 (t4 r1 i0/0 o0/0 fd 16/16 cfd -1)\r\n #4 X11 connection from 127.0.0.1 port 57565 (t4 r2 i0/0 o0/0 fd 17/17 cfd -1)\r\n #5 X11 connection from 127.0.0.1 port 57566 (t4 r3 i0/0 o0/0 fd 18/18 cfd -1)\r\n #6 X11 connection from 127.0.0.1 port 57567 (t4 r4 i0/0 o0/0 fd 19/19 cfd -1)\r\n #7 X11 connection from 127.0.0.1 port 59007
Neste relatório, tudo é o mesmo entre os relatórios de status, exceto o número da porta usado pela conexão # 7, que acredito ser o cliente Linux - o único que ainda mantém uma conexão de exibição. Ele continua a aumentar ao longo do tempo, a julgar por uma sequência desses relatórios durante a noite.
Obrigado por qualquer ajuda,
-Mike
As sessões ssh começaram depois que mudei o / etc / ssh_config do cliente Mac para incluir a linha:
ForwardX11Timeout 596h
estão todos funcionando bem e foram o dia todo. A essa altura, todos eles teriam se recusado a iniciar novos xterms. Então eu acredito que esta é a resposta, e felizmente uma solução simples, mas o tempo limite ainda vai acontecer daqui a 3/2/2 semanas.
man ssh_config
ForwardX11Trusted
If this option is set to "yes" remote X11 clients will have full access to the original X11 display. If this option is set to "no" remote X11 clients will be considered untrusted and prevented from stealing or tampering with data belonging to trusted X11 clients. Furthermore, the xauth(1) token used for the session will be set to expire after 20 minutes. Remote clients will be refused access after this time. The default is "no" See the X11 SECURITY extension specification for full details on the restrictions imposed on untrusted clients.