X problema de tunelamento da máquina remota

Question

Estou tentando encapsular uma janela x. Se a fazer:

user@local: ssh -X user@remote  xclock

funciona. No entanto, se eu fizer login na máquina primeiro e, em seguida, iniciar o programa, ele falhará.

user@local: ssh -X user@remote

user@remote: xclock
No protocol specified
Error: Can't open display: :0

O que deu errado?

Editar

Eu verifiquei a variável $DISPLAY no controle remoto:

user@local: ssh -X user@remote "echo $DISPLAY"
:0.0

definindo o mesmo valor no controle remoto depois que o login não funcionar. Definindo $DISPLAY como :10.0 como trabalhos sugeridos.

user@local: ssh -X user@remote
user@remote: DISPLAY=:10.0 xclock

Ainda não entendi por que preciso de valores $ DISPLAY diferentes para a sessão interativa e não interativa.

    

Answer 1

Verifique se a variável DISPLAY está definida corretamente para localhost: 10.0 . Se não for,

export DISPLAY=localhost:10.0 

, então tente xclock novamente.

But why do I need 'DISPLAY' to be 10.0 instead of 0.0?

O servidor X (ou X Window , ou X11 ) é exatamente isso, um servidor, aguardando que os aplicativos se conectem a ele para exibi-los. Isso ocorre no seu pc, onde os aplicativos se conectam ao servidor X por meio de um soquete localizado em / tmp , normalmente chamado de /tmp/.X11-unix . No entanto, como todos os servidores, o X11 pode ser contatado a partir de computadores remotos e exibe aplicações gráficas que são executadas em computadores remotos.

No entanto, essa habilidade traz muitos riscos de segurança, de modo que a abertura do seu servidor X11 para aplicativos remotos é muito difícil (você precisa especificar a mesma opção pelo menos três vezes, em arquivos de configuração diferentes).

Agora digite ssh , o que torna isso seguro: é a opção -Y / -X ssh que lida com segurança (também criptografando o tráfego) todos os detalhes da abertura do seu servidor X11 local para o aplicativo remoto. Entretanto, quando você quiser exibir o xclock remoto localmente, você deve instruir o aplicativo remoto para o qual o servidor X11 a ser contatado não é seu próprio servidor X11, mas é um em um PC distante (aquele a partir do qual você iniciou a sessão ssh ). Então xclock deve enviar sua saída não para um socket local em / tmp mas para uma porta de rede (é 127.0.0.1: 6010 , que ssh misericordiosamente encurta para localhost: 10 ), do qual ssh se encarregará de enviá-lo de volta ao seu local pc, onde eventualmente a saída é exibida graficamente.

Se você não gostar das diferentes conexões ssh (você pode ter várias) para serem separadas por 10 unidades, como em localhost: 10.0, localhost: 20.0, ... ) você deve mudar a declaração

X11DisplayOffset 10

em / etc / ssh / sshd_config para o que você quiser (embora eu não consiga ver nenhuma razão para isso, para ser honesto).

É esta declaração que faz com que os displays remotos estejam disponíveis não na porta 6000 (que seria localhost: 0.0 ), mas na porta 6010 . Você pode verificar isso sozinho:

$ ssh -Y vps
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Apr 17 02:47:42 2017 from 
root@vps:~# ss -lntp | grep 6010
LISTEN     0      0                 127.0.0.1:6010                     *:*      users:(("sshd",16172,8))
LISTEN     0      0                       ::1:6010                    :::*      users:(("sshd",16172,7))