Raspberry pi 3 * área de trabalho remota reversa *

Question

Eu tenho máquina local (A) e Raspberry PI 3 (B).
B tem monitor HDMI conectado e está executando o Raspbian OS.

Eu quero rodar o aplicativo X em uma - digamos, apresentação Libre Office Impress que tenho em A, e tê-lo visível (ser exibido em) na tela conectada a B.
Eu quero fazer isso na frente de uma máquina:

• não por ssh -X to_A de B,
• nem usando VNC de B para obter saída de A

Eu não estou procurando:

• Executando o aplicativo X em B usando ssh de A e tendo sua saída exibida em A (isso pode ser feito por clientes from_a $ ssh -X machine_B ou rdp / remmina / vnc)
• Executando o aplicativo X em B usando ssh de A e tendo sua saída exibida em B (isso pode ser feito exportando a exibição em ssh e a configuração adequada de xhost, por exemplo, from_a $ ssh machine_b from -> at_a_but_sshed_onto_b $ xhost + && export DISPLAY=:0 xeyes )
• solução que requer acesso físico direto a B

O que eu tentei foi o setup (B) para executar itens X remotos ... se não me esqueci de nada - já que nmap -p6000 machine_B retornou que a porta está fechada , e rodando (da linha de comando de A):

A_machine $ env DISPLAY=B_machine:0 xeyes

em que B_machine está definido em /etc/hosts , bem como ~/.ssh/config falha.

O que eu suspeito, é que eu sinto falta de copiar o X11 magic_cookies de .Xauthority ... mas talvez este passo não seja necessário e haja uma maneira mais simples?

Editar: em resposta à pergunta @Rostislav Kandilarov - parece que o lightdm inicia o servidor X, mas logo eu poderei verificar sua segunda-feira, assim como verificar se ele começa com --nolisten tcp .

    

Answer 1

(Editado, resposta antiga abaixo)

Com o requisito adicional de fazer tudo isso de A, sem tocar em B, o problema de executar um servidor X em B e conectar-se a ele com um aplicativo em A é que esse servidor X utilizará apenas dispositivos de entrada ( teclado, mouse) conectado a B. Então, para usar seu aplicativo, você teria que usar esses dispositivos de entrada, o que você não quer.

Em princípio, você poderia tentar compartilhar os dispositivos de entrada de A, mas a construção realmente começa a ficar bizantina ...

Então VNC é muito mais fácil nesta situação.

Configure um vnc4server em A. Este servidor também atuará como servidor X para aplicativos em A. Inicie um xvnc4viewer em A e use-o para iniciar e controlar seu aplicativo. Inicie outro vncviewer em B e conecte-o ao servidor em A, ele exibirá o aplicativo. Pode ser tão simples quanto directvnc (use o framebuffer do RaspPi diretamente, nenhum desvio adicional sobre o X, portanto menos carga de trabalho para o RaspPi), ou se você quer continuar rodando um servidor X existente no B, anoth xvnc4viewer .

A maneira mais fácil é usar uma área de trabalho remota como VNC , muito provavelmente já disponível como um pacote em sua distribuição. Isso funciona normalmente muito melhor que o X encaminhamento via ssh ou de outra forma, porque é muito melhor comprimido e não usa primitivas X no fio.

É claro que também existem várias maneiras de configurar o encaminhamento do X, por meio do ssh ou diretamente. Por exemplo, você pode fazer login via ssh -X de B para A, executar seu aplicativo em A e ter a saída exibida em B. (Você descartou a direção inversa, mas não disse nada sobre isso, então eu ' Não tenho certeza se você quer isso).

Você também pode configurar o servidor X para uma sessão remota via XDMCP . Ou faça um único aplicativo usar um servidor X remoto usando as configurações xauth e DISPLAY adequadas.

Mas eu ainda recomendo testar o VNC primeiro.

    

Answer 2

Então, se você estiver usando o Raspbian OS em (B), se você não fez nenhuma customização específica como você suspeitou, provavelmente você está usando lightdm.

Certamente você precisa dizer ao lightdm para forçar o servidor X a escutar o tcp (porta 6000). Você faz isso configurando xserver-allow-tcp=true no arquivo conf na seção global [Seat:*] . Você também pode precisar especificar explicitamente xserver-command=X -listen tcp (dê uma olhada aqui ). É sua escolha entre qualquer arquivo extra em /etc/lightdm/lightdm.conf.d/*.conf ou diretamente em /etc/lightdm/lightdm.conf .

Em seguida, se você não se importar muito com a segurança, provavelmente também precisará executar (B) alguma forma de comando xhost + como xhost + IP_OF_(A) . Se você se preocupa com vulnerabilidades de LAN você não deve usar diretamente X em tcp em primeiro lugar, mas sem ssh você pode dar um pouco de dureza trocando um MIT-MAGIC-COOKIE entre (A) e (B ) rodando em (B) xauth extract - $DISPLAY | ssh (A) xauth merge - .

Em seguida, reinicie o lightdm service lightdm restart ou systemctl restart lightdm.service , dependendo da versão do sistema operacional.

Last - verifique (B) se o Xorg está escutando em 6000 netstat -antp | grep -F 6000