¿Cómo habilitar el reenvío SSH X11 a través de un servidor adicional?


33

Tengo los hosts A, B y C. Desde el host AI solo puedo acceder a través de ssh B. Desde BI puedo acceder a C. Quiero poder ejecutar programas X11 en C y reenviar la pantalla a A.

Intenté esto:

A $ ssh -XB
B $ ssh -XC
C $ xclock
Error: no se puede abrir la pantalla:

Pero no funciona.

Respuestas:


25

Hay varias formas de hacer esto, la que prefiero es reenviar el puerto ssh:

Primero, conéctese a la máquina B y envíe [localPort] a C: 22 a B

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

Luego, conéctese a C desde A a través de este túnel recién creado usando [localPort], reenviando X11

A$ ssh -X -p [localPort] localhost

Ahora podemos ejecutar programas X11 en C y hacer que se muestren en A

C$ xclock

[localPort] puede ser cualquier puerto que aún no esté escuchando en A, a menudo uso 2222 por simplicidad.


3
no exactamente ... si X11Forwarding no está habilitado en el servidor C, no funcionará. tampoco funcionará a menos que se establezca AllowTcpForwarding yes y GatewayPorts yes en el servidor B. esta respuesta no es aceptable en absoluto
asdmin

Haces un buen punto, no lo noté porque utilizo debian, en el que X11Forwarding y AllowTcpForwarding están habilitados de forma predeterminada. GatewayPorts no es necesario ya que cuando está deshabilitado, SSH todavía escucha en localhost y eso es a lo que nos estamos conectando. Solo lo necesitaría si desea realizar la segunda conexión a través de una IP externa para la máquina A.
Dave

En el paso 1, no me pidió la contraseña para el host B, y terminé conectado en el host C. En otra ventana intenté el paso 2 y obtengo "ssh_exchange_identification: conexión cerrada por host remoto".
msb

ssh: conectarse al host ... puerto 22: conexión rechazada mientras se ejecuta el primer comando
Rodrigo

7

Esto se puede lograr fácilmente mediante el reenvío de puertos:

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

Puerto localhost: 2022 se reenvía a C: 22 a través de B SSH a C a través de localhost: 2022 Utilice X como normal


2
Esto no funcionará por las mismas razones señaladas en otro lugar en caso de que B (la puerta de enlace) no tenga habilitadas las opciones de reenvío sshd correctas.
g33kz0r

no solicitó mi contraseña para alojar B, lo cual es extraño; y no funcionó, recibí el mensaje de error "canal 2: error de apertura: prohibido administrativamente: error de apertura ssh_exchange_identification: conexión cerrada por host remoto"
msb

4

Suponiendo que el problema es que la máquina central no tiene X, pero de lo contrario está configurada para permitir el reenvío de X11, solo instale xauth.

en un sistema basado en yum (fedora, redhat, centos):

B$ sudo yum install xauth

en un sistema basado en apt (debian, ubuntu):

B$ sudo apt-get install xauth

Sí, perfecto para frambuesa pi sin cabeza.
cmc

@cmc o usando ssh como un vpn.
Jayen

@cmc tienes yumen un pi?
Jayen

nope- sudo apt-get install xauth
cmc

3

Para versiones más recientes de opensshd, debe deshabilitarlo X11UseLocalhostpara que esto funcione.

Debe hacer esto en el Host C /etc/ssh/sshd_configy reiniciar sshd para que esto funcione:

X11Forwarding yes
X11UseLocalhost no

2

No puede reenviar la pantalla X11 si tiene deshabilitado el reenvío X11 en cualquier sshd que esté utilizando.

man sshd_config:

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

Debe asegurarse de que X11Forwarding esté habilitado en el destino y todos los sshds intermedios que esté utilizando.

Solo una pequeña pista: debe intentar usar VNC, el reenvío de pantalla X11 consume bastante ancho de banda.


Las sugerencias de @ AgentK y @ ​​dave solo requieren que X11Forwarding esté habilitado en el host final, ya que utilizan un túnel SSH para evitar el host intermedio. Su sugerencia es casi definitivamente por qué el método del OP falló al principio, pero eso no significa que las respuestas de otras personas "no son aceptables"
Daniel Lawson

sus respuestas fueron defectuosas y remediaron el problema, no lo resolvieron. una respuesta correcta y útil consideraría la pregunta original y la resolvería, y proporcionaría otras formas solo en caso de que la pregunta original no se pueda resolver. Por cierto, ninguno de ellos mencionó X11 Forwarding, lo cual es esencial
asdmin

En algunos sistemas, el valor predeterminado es " yes".
Brad Gilbert el

Verifiqué que X11Forwarding está habilitado en B y C y AllowTcpForwarding está establecido en yes en B. Pero el resultado de mis comandos es el mismo. Y la respuesta de Dave funciona bien para mí.
lexsys

entonces haz eso, pero es solo un remedio. también puede iniciar ssh con el parámetro '-v', o probar echo $ DISPLAY todos los comandos ssh anidados para descubrir dónde se pierde $ DISPLAY
asdmin

2

Si a menudo va de A a C, puede configurar B como proxy:

A:~/.ssh/config:

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

entonces es solo:

A$ ssh C xclock

1

¿Has intentado con

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

El indicador -Y "Habilita el reenvío de confianza de X11".


El mismo resultado.
lexsys

Esto funcionó para mí, pero solo para descubrir qué tan lento es X11
Rodrigo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.