Eu quero executar um aplicativo GUI em uma máquina remota que eu só tenho acesso ssh. Não preciso nem quero ver a janela da GUI. (Eu sei que eu poderia usar algo como ssh -C -X remote_server se eu quisesse que a GUI estivesse no meu cliente.)
Eu sei que o X está sendo executado na máquina remota, pois ps mostra isso:
root ... /usr/bin/Xorg :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
Eu defino DISPLAY=:0.0 , mas depois recebo "Xlib: connection to": 0.0 "recusado pelo servidor" quando tento usá-lo.
Em Obtenha o display x remoto trabalhando no linux sem ssh tunneling e Xserver não funciona a menos que DISPLAY = 0.0 Eu vejo o conselho para usar o gdmsetup para permitir que o X ouça o TCP. Mas o gdmsetup é uma aplicação GUI! E tentar executá-lo por ssh -X não funcionou ("conexão X11 rejeitada por causa da autenticação incorreta").
Então, existe um arquivo de texto que eu possa editar para remover -nolisten ? E, depois de editá-lo, como reiniciar o X remotamente? (Há outras coisas rodando nesta máquina, então requisitar uma reinicialização é possível, mas indesejável.) Se não, deve gdmsetup ser capaz de rodar sobre o ssh e eu deveria perseverar nessa direção?
UPDATE: Eu tive que fazer a sessão ssh -X como root (ssh como um usuário normal, então sudo ou su, não funciona.) Então, eu fiz a edição com o gdmsetup. Eu reiniciei o X com gdm-restart . Eu também fiz xhost + dessa sessão ssh -X. A linha ps não mostra mais a parte -nolisten tcp . Mas ainda não há sorte em se conectar a ele, com DISPLAY=:0 ou DISPLAY=localhost:0
UPDATE # 2: Eu só notei o motivo xauth + não ajudou (quando feito sobre ssh -X ) foi alterado minha máquina cliente, não o servidor remoto! Oops Bom trabalho eu estava dentro do firewall! (Eu acho que a razão para isso ter sido relacionada à variável ambiental XAUTHORITY, veja a resposta de Cougar.)
como parece que você deseja que seu aplicativo seja anexado à raiz da sessão no momento: a tela de login do gdm.
por que você não inicia seu próprio xserver e seu programa:
%> startx /your/program -- :1
(Adicionado por Darren) Aqui está precisamente o que eu fiz. Em uma sessão ssh, torne-se root e digite:
startx -- :1 &
export DISPLAY=:1
xhost + &
Em seguida, em outra sessão ssh, usuário normal:
export DISPLAY=:1
xclock
(Apenas usando o xclock como um teste.)
Se você só precisa se conectar ao monitor X que está sendo executado remotamente e iniciar seu programa, então é apenas um problema de autorização que você tem. Agora, depende de como a autorização está configurada.
Uma maneira é usar xhost e conceder permissões por IP, mas isso é altamente inseguro, porque qualquer programa em execução nesta máquina (ou qualquer máquina, se você usar apenas +), pode se conectar automaticamente ao servidor de dislay do X.
A maneira comum é usar o arquivo de autoridade X. Então você só precisa conhecer esse arquivo e ter acesso a ele. Agora, isso depende da distribuição, se esse arquivo for .Xauthority em seu diretório inicial ou algum arquivo temporário for configurado toda vez que você iniciar a sessão X.
No primeiro caso, tudo funciona fora da caixa, no último caso, você precisa saber esse nome de arquivo temporário. Uma maneira de descobrir isso é olhar para a variável XAUTHORITY no ambiente de algum programa (como o gerenciador de janelas) já em execução no seu servidor X. Você pode obter facilmente variáveis de ambiente a partir do arquivo / proc / PID / environ assim:
cat /proc/12345/environ | xargs -0 -L 1 echo | grep XAUTHORITY
Em seguida, basta exportar variáveis XAUTHORITY e DISPLAY para o seu shell e iniciar seu programa
Parece que você está indo muito bem para fazer isso funcionar. Como alternativa, eu poderia recomendar a instalação do FreeNX na máquina remota e acessá-lo com o NXClient. Você obterá uma área de trabalho remota completa via ssh e poderá abrir a janela do terminal e executar o aplicativo. Isso levará menos tempo do que tentar descobrir o tunelamento com ssh.
Tags xorg remote-access linux