Como habilitar o encaminhamento do SSH X11 através de um servidor adicional?


33

Eu tenho os hosts A, B e C. No host AI, é possível acessar apenas pelo ssh B. No BI, é possível acessar C. Quero poder executar programas X11 em C e encaminhar a exibição para A.

Eu tentei isso:

A $ ssh -XB
B $ ssh -XC
C $ xclock
Erro: Não é possível abrir a tela:

Mas isso não funciona.

Respostas:


25

Existem várias maneiras de fazer isso, o que eu prefiro é encaminhar a porta ssh:

Primeiro, conecte à máquina B e encaminhe [localPort] para C: 22 a B

A$ ssh -L [localPort]:C:22 B

Em seguida, conecte-se a C de A através deste túnel recém-criado usando [localPort], encaminhando o X11

A$ ssh -X -p [localPort] localhost

Agora podemos executar programas X11 em C e exibi-los em A

C$ xclock

[localPort] pode ser qualquer porta que você ainda não esteja ouvindo em A, geralmente uso 2222 para simplificar.


3
não exatamente ... se o X11Forwarding não estiver ativado no servidor C, ele não funcionará. ele também não vai funcionar a menos que se propõe AllowTcpForwarding sim e GatewayPorts sim no servidor B. esta resposta não é aceitável em tudo
asdmin

Você fez um bom argumento, eu não percebi isso porque uso o debian, no qual o X11Forwarding e o AllowTcpForwarding são ativados por padrão. O GatewayPorts não é necessário, pois quando está desabilitado, o SSH ainda escuta no host local e é com isso que estamos nos conectando. Você só precisa se você queria fazer a segunda ligação através de um IP externo para a máquina A.
dave

Na etapa 1, ele não me pediu a senha do host B e eu acabei conectado no host C. Em outra janela, tentei a etapa 2 e recebo "ssh_exchange_identification: conexão fechada pelo host remoto".
MSB

ssh: conectar ao host ... porta 22: Conexão recusada durante a execução do primeiro comando
Rodrigo

7

Isso pode ser feito facilmente usando o encaminhamento de porta:

A$ ssh -NL 2022:C:22 B &
A$ ssh -X -p 2022 localhost
C$ xclock

A porta localhost: 2022 é encaminhada para C: 22 via B SSH para C via localhost: 2022 Use X normalmente


2
Isso não funcionará pelos mesmos motivos mencionados em outros lugares, caso o B (o gateway) não tenha as opções de encaminhamento sshd corretas ativadas.
precisa saber é o seguinte

não pedi minha senha para hospedar B, o que é estranho; e não funcionou, recebi a mensagem de erro "canal 2: falha na abertura: proibido administrativamente: falha na abertura ssh_exchange_identification: conexão fechada por host remoto"
msb

4

Assumindo que o problema é que a máquina do meio não possui X, mas configurada para permitir o encaminhamento do X11, basta instalar o xauth.

em um sistema baseado em yum (fedora, redhat, centos):

B$ sudo yum install xauth

em um sistema baseado em apt (debian, ubuntu):

B$ sudo apt-get install xauth

Yay - perfeito para pi framboesa sem cabeça.
Cmc #

@cmc ou usando ssh como um vpn.
21418 Jayen

@cmc você tem yumem um pi?
21418 Jayen

nope- sudo apt-get install xauth
cmc

3

Para versões mais recentes do opensshd, é necessário desativar X11UseLocalhostpara que isso funcione.

Você precisa fazer isso no host C /etc/ssh/sshd_confige reiniciar o sshd para que isso funcione:

X11Forwarding yes
X11UseLocalhost no

2

Você não pode encaminhar a exibição do X11 se o X11Forwarding estiver desativado em qualquer sshd que estiver usando.

man sshd_config:

X11Forwarding
  Specifies whether X11 forwarding is permitted. The argument must be “yes”
  or “no”.  The default is “no”.

Você precisa garantir que o X11Forwarding esteja ativado no destino e em todos os sshds intermediários que você estiver usando.

Apenas uma pequena dica: você deve tentar usar o VNC, o encaminhamento de tela X11 consome bastante largura de banda.


As sugestões dos @ AgentK e @ dave exigem apenas que o X11Forwarding seja ativado no host final, pois eles usam um túnel SSH para ignorar o host intermediário. Sua sugestão é quase certamente por isso que o método do OP falhou no início, mas que faz respostas não significa outras pessoas "não são aceitáveis"
Daniel Lawson

suas respostas estavam com defeito e solucionaram o problema, sem resolvê-lo. uma resposta correta e útil consideraria a questão original e a solucionaria, fornecendo outras maneiras apenas no caso de a questão original não ser solucionável. aliás, nenhum dos dois mencionou X11Forwarding, que é essencial
asdmin

Em alguns sistemas, o padrão é " yes".
23411 Brad Gilbert

Eu verifiquei que X11Forwarding está ativado em B e C e AllowTcpForwarding está definido como yes em B. Mas o resultado dos meus comandos é o mesmo. E a resposta de Dave funciona bem para mim.
lexsys 19/08/09

então faça isso, mas é apenas um remédio. você também pode começar ssh com o parâmetro '-v', ou tentar echo $ DISPLAY todos os comandos ssh aninhados para encontrá-lo onde $ DISPLAY se perder
asdmin

2

Se você costuma ir de A a C, pode configurar B como um proxy:

A:~/.ssh/config:

Host C
  ForwardX11   yes
  ProxyCommand ssh -W %h:%p B

então é só:

A$ ssh C xclock

1

Você já tentou com

A$ ssh -Y B
B$ ssh -Y C
C$ xlclock

O sinalizador -Y "Ativa o encaminhamento confiável do X11".


O mesmo resultado.
lexsys 12/08/09

Isso funcionou para mim, mas apenas para descobrir quão lento é X11
Rodrigo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.