Comment activer le transfert SSH X11 via un serveur supplémentaire?


33

J'ai des hôtes A, B et C. À partir de l'hôte, l'IA ne peut accéder à ssh qu'à partir de B. De la BI, il est possible d'accéder à C. Je veux pouvoir exécuter des programmes X11 sur C et transmettre l'affichage à A.

J'ai essayé ceci:

A $ ssh -XB
B $ ssh -XC
C $ xclock
Erreur: Impossible d'ouvrir l'affichage:

Mais ça ne marche pas.

Réponses:


25

Il y a plusieurs façons de procéder, celle que je préfère consiste à transférer le port ssh:

Commencez par vous connecter à la machine B et envoyez le [port local] vers C: 22 à B

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

Ensuite, connectez-vous au C depuis A via ce tunnel nouvellement créé en utilisant [localPort], en transférant X11.

A$ ssh -X -p [localPort] localhost

Maintenant, nous pouvons exécuter des programmes X11 sur C et les afficher sur A

C$ xclock

[localPort] peut être n'importe quel port que vous n'écoutez pas déjà sur A, j'utilise souvent 2222 pour plus de simplicité.


3
pas exactement ... si X11Forwarding n'est pas activé sur le serveur C, cela ne fonctionnera pas. cela ne fonctionnera pas non plus si on ne définit pas AllowTcpForwarding yes et GatewayPorts yes sur le serveur B. Cette réponse n'est pas acceptable du tout
asdmin

Vous faites valoir un point, je ne l’ai pas remarqué depuis que j’utilise debian, sur lequel X11Forwarding et AllowTcpForwarding sont activés par défaut. GatewayPorts n'est pas nécessaire, car lorsqu'il est désactivé, SSH écoute toujours sur localhost et c'est à cela que nous nous connectons. Vous n'en aurez besoin que si vous souhaitez établir la deuxième connexion via une adresse IP externe pour la machine A.
dave

À l'étape 1, il ne m'a pas demandé le mot de passe de l'hôte B et je me suis connecté à l'hôte C. Dans une autre fenêtre, j'ai essayé l'étape 2 et j'ai obtenu "ssh_exchange_identification: Connexion fermée par l'hôte distant".
msb

ssh: se connecter à l'hôte ... port 22: connexion refusée lors de l'exécution de la première commande
Rodrigo

7

Ceci peut facilement être accompli en utilisant la redirection de port:

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

Port localhost: 2022 est transmis à C: 22 via B SSH à C via localhost: 2022 Utilisez X comme d'habitude


2
Cela ne fonctionnera pas pour les mêmes raisons que celles mentionnées ailleurs dans le cas où B (la passerelle) ne dispose pas des options de transfert sshd correctes activées.
g33kz0r

n'a pas demandé mon mot de passe pour héberger B, ce qui est bizarre; et cela n'a pas fonctionné, j'ai reçu le message d'erreur "canal 2: échec de l'ouverture: interdiction administrative: échec de l'ouverture ssh_exchange_identification: connexion fermée par l'hôte distant"
msb

4

En supposant que le problème est que la machine intermédiaire ne possède pas X, mais si elle est configurée pour autoriser le transfert de X11, il suffit d'installer xauth.

sur un système à base de yum (fedora, redhat, centos):

B$ sudo yum install xauth

sur un système basé sur apt (debian, ubuntu):

B$ sudo apt-get install xauth

Yay- parfait pour pi framboise sans tête.
cmc

@ cmc ou en utilisant ssh comme un vpn.
Jayen

@ cmc avez-vous yumsur un pi?
Jayen

nope- sudo apt-get install xauth
cmc

3

Pour les versions plus récentes opensshd, vous devez le désactiver X11UseLocalhostpour que cela fonctionne.

Vous devez le faire sur l'hôte C /etc/ssh/sshd_configet redémarrer sshd pour que cela fonctionne:

X11Forwarding yes
X11UseLocalhost no

2

Vous ne pouvez pas transférer l’affichage X11 si vous avez désactivé X11Forwarding dans n’importe quel fichier sshd que vous utilisez.

man sshd_config:

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

Vous devez vous assurer que X11Forwarding est activé sur la destination et sur tous les sshds intermédiaires que vous utilisez.

Juste un petit indice: vous devriez essayer d'utiliser VNC, le transfert d'affichage X11 consomme beaucoup de bande passante.


Les suggestions de @ AgentK et de @ dave nécessitent uniquement l'activation de X11Forwarding sur l'hôte final, car ils utilisent un tunnel SSH pour contourner l'hôte intermédiaire. Votre suggestion est presque certainement la raison pour laquelle la méthode du PO a échoué au début, mais cela ne signifie pas que les réponses des autres personnes "ne sont pas acceptables"
Daniel Lawson,

leurs réponses étaient défectueuses et ont résolu le problème, pas le résoudre. une réponse juste et utile prendrait en compte la question initiale et la résoudre, et ne fournirait d'autres moyens que dans le cas où la question initiale ne serait pas résolue. à propos, aucun d'eux n'a mentionné X11Forwarding, ce qui est essentiel
asdmin

Sur certains systèmes, la valeur par défaut est " yes".
Brad Gilbert

J'ai vérifié que X11Forwarding est activé sur B et C et que AllowTcpForwarding a la valeur yes sur B. Mais le résultat de mes commandes est identique. Et la réponse de Dave me convient parfaitement.
lexsys

alors faites-le, mais ce n'est qu'un remède. vous pouvez également démarrer ssh avec le paramètre '-v', ou essayer echo $ DISPLAY toutes les commandes ssh imbriquées pour savoir où se trouve $ DISPLAY se perdre
asdmin

2

Si vous passez souvent de A à C, vous pouvez configurer B en tant que proxy:

A:~/.ssh/config:

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

alors c'est juste:

A$ ssh C xclock

1

Avez-vous essayé avec

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

L'indicateur -Y "Active le transfert X11 de confiance".


Le même résultat.
lexsys

Cela a fonctionné pour moi, mais seulement pour découvrir à quel point X11 est lent
Rodrigo
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.