Réponses:
Vous pouvez créer une deuxième connexion avec le transfert X11 activé, puis vous pouvez également utiliser la DISPLAY
variable d'environnement de la deuxième connexion dans la première.
Dans la 1ère fenêtre:
$ ssh user@host
user@host$ ...
Dans la 2ème fenêtre:
$ ssh -Y user@host 'echo $DISPLAY; while sleep 3600; do :; done'
localhost:10.0
Retour à la 1ère fenêtre:
user@host$ export DISPLAY=localhost:10.0
user@host$ xterm
Malheureusement, ssh
ne fait rien pour contenir les transferts X11 (ou autres) vers le processus / session qu'il a démarré ou vers l'utilisateur qu'il exécute comme sur la machine distante (par exemple en utilisant des sockets Unix avec / sans vérifier les informations d'identification, ou en utilisant des espaces de noms), et ces transferts sont de simples sockets d'écoute TCP auxquels n'importe qui sur la machine distante peut se connecter; toute la sécurité du transfert X11 repose sur l'authentification X11.
La sshd_config(5)
page de manuel mentionne que:
la désactivation du transfert X11 n'empêche pas les utilisateurs de transférer le trafic X11, car les utilisateurs peuvent toujours installer leurs propres redirecteurs.
Voici comment vous pouvez le faire à la main.
Tout d'abord, assurez-vous de désactiver tout contrôle d'accès basé sur l'hôte ou l'utilisateur qui contourne le mécanisme d'authentification x11 [1]:
$ xhost $(xhost | sed -n /:/s/^/-/p)
access control enabled, only authorized clients can connect
Ensuite, affichez les informations d'authentification pour DISPLAY=:0
sur la machine locale:
$ xauth list :0
ohzd/unix:0 MIT-MAGIC-COOKIE-1 a86982ddce0c1e1c1a8c5e8b2846e43b
Connectez-vous à la machine distante sans aucun transfert X11:
$ ssh user@hzy64
user@hzy64's password:
[motd snipped]
Ouvrez la ligne de commande via ~C
et ajoutez une redirection à distance du port 6000+43
vers le socket Unix correspondant à l'affichage :0
:
hzy64$~C
ssh> -R 6043:/tmp/.X11-unix/X0
Forwarding port.
Définissez l' $DISPLAY
envvar et ajoutez les informations d'authentification du local à la machine distante:
hzy64$ export DISPLAY=localhost:43
hzy64$ xauth add $DISPLAY . a86982ddce0c1e1c1a8c5e8b2846e43b
xauth: file /home/user/.Xauthority does not exist
Vous êtes maintenant prêt à partir:
hzy64$ xterm
[1] en raison d'une correction de bogue erronée , le contrôle d'accès basé sur l'utilisateur est activé par défaut dans Debian via /etc/X11/Xsession.d/35x11-common_xhost-local
. Pire, c'est le seul disponible par défaut dans XWayland où il ne peut pas non plus être désactivé . Tout programme mandataire du protocole X11 (par exemple xscope
) devra effectuer sa propre vérification de cookie d'authentification x11 (comme le fait ssh), à moins qu'il ne veuille ouvrir un trou béant au serveur X11.
-X
serait un peu mieux que -Y
, non?
-X
, seulement avec -Y
. les gens ne le remarquent pas parce que sur de nombreux systèmes (par exemple, debian) ForwardX11Trusted
est défini yes
par défaut, et les options -X
et -Y
sont équivalentes ;-)
change $DISPLAY to
. Le titre de la question actuelle ne peut pas être affiché dans son intégralité dans les résultats de recherche, et la modification de $ DISPLAY fait vraiment partie de la réponse, pas de la question.