Não é possível iniciar o xterm sobre o ssh após vários sucessos

Question

Estou executando alguns scripts do MATLAB na linha de comando de um computador remoto usando ssh . Esses scripts iniciam 5 xterms que são encaminhados para mim via ssh (usando a opção -X ). No momento estou depurando meu código, então estou reiniciando meus scripts de vez em quando. Tudo funciona bem para algumas execuções, mas depois da N'ésima hora (onde N é um número aleatório) eu recebo essas mensagens de erro:

xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0
xterm Xt error: Can't open display: localhost:10.0

Depois disso, posso continuar a usar o ssh, exceto para iniciar qualquer coisa relacionada à GUI, o que significa que não posso mais iniciar xterms remotamente. Minha única solução é reiniciar a conexão ssh. Posso consertar isso de alguma forma para nunca ser incomodado novamente por isso?

Sistema

• sistema local: laptop de propriedade privada, executando o Chakra Linux, KDE
• sistema remoto: computador da universidade, executando openSuSe, KDE

Answer 1

O SSH bloqueia novas conexões X11 após 20 minutos em sua configuração padrão. Para evitar isso, execute ssh -Y em vez de ssh -X ou defina a opção ForwardX11Trusted yes em ~/.ssh/config .

Se você executar ssh -v , verá a mensagem “Conexão X11 rejeitada após a expiração de ForwardX11Timeout” quando um novo aplicativo tentar se conectar à exibição após o tempo limite. Sem -v (que causa muitos outros resultados de depuração), todas as informações que você obtém são “Não é possível abrir a exibição”.

Para explicar por que, preciso dar um pouco de conhecimento. O encaminhamento X11 permite que a máquina de destino entre em contato com o servidor X local. Isso tem consequências em termos de segurança. Um servidor X11 não isola os aplicativos uns dos outros; isso permite que o gerenciador de janelas mova as janelas e as mate como quiser, permite que as ferramentas de processamento de macros façam isso também e injetem pressionamentos de teclas e assim por diante. Além disso, qualquer aplicativo pode ler e modificar a área de transferência. Isso dá muito poder a aplicações remotas sobre seus dados locais. Se a máquina remota não for confiável, com uma conexão em modo de texto, o pior que pode acontecer são coisas ruins na máquina remota. Mas com uma conexão X11 sem restrições, coisas ruins podem acontecer em sua máquina local também.

O X11 inclui a " extensão SECURITY ", que permite que alguns aplicativos sejam declarados como não confiável. Aplicativos não confiáveis recebem menos direitos, por exemplo, não podem monitorar ou injetar pressionamentos de tecla em outros aplicativos. O SSH fornece a opção de declarar a conexão como confiável ( ForwardX11Trusted yes ou ssh -Y ) ou não confiável ( ForwardX11Trusted no ou ssh -X ).

O SSH tem, por muito tempo, padronizado o estabelecimento de conexões não confiáveis. Como um recurso de segurança adicional, conexões não confiáveis só podem ser estabelecidas por alguns minutos no início da sessão SSH; originalmente 2 minutos ( ssh.c 1.202 ), depois 20 minutos ( ssh.c 1.207 ). Como um recurso de segurança, não vejo o ponto: se você já está executando um aplicativo não confiável, se um outro aplicativo pode ser lançado posteriormente é discutível. Versões recentes do SSH ( ssh.c 1.340 , clientloop.c 1.221 ) fez o tempo limite configurável com o ForwardX11Timeout .

Infelizmente, devido a um bug no X.org não pode definir um valor muito alto de ForwardX11Timeout , senão o servidor X irá falhar .

As conexões confiáveis não estão sujeitas a este mecanismo de expiração. A desvantagem é que um malware ou um administrador mal-intencionado na máquina remota pode assumir o controle de sua máquina local. Isso geralmente é aceitável, mas cabe a você decidir.

    

Answer 2

Eu tentei tudo isso, mas ainda tinha o mesmo problema "Nenhum protocolo especificado", Se alguém está enfrentando o mesmo depois de tentar todas as soluções, eu posso dizer que não é nada complicado,

Encontrei uma mensagem de erro no meu arquivo de log do Xming. Xming (executando na barra de tarefas) > > visualizar o arquivo de registro ...

Assim, você pode reiniciar o sistema e executar o Xming, se o Xming estiver funcionando corretamente, o arquivo de log terá mais linhas. Então faça o mesmo # export DISPLAY="IP:0.0" , deve funcionar agora.

Eu tive outro problema com 2 monitores, e eu encontrei a mesma mensagem "Nenhum protocolo especificado", não foi esclarecido que o problema é para o segundo monitor. Então eu parei de um monitor, se você quiser usar vários monitores aqui está o comando

Xming -query <IP address of remote host> -nodecoration -screen 0 @2 -clipboard