From: Henrik.Carlqvist@deadspam.com   
      
   On Fri, 21 Oct 2022 23:37:13 +0000, Harold Johanssen wrote:   
      
   > I have a Slackware 15.0 host A running a TigerVNC session on display 1.   
   > I can connect to that session from another Slackware 15.0 system with   
   > vncviewer tunneled within an sshSSH channel. I can also ssh into B from   
   > a terminal emulator in A.   
   >   
   > 	What I would like to do is the following:   
   >   
   > 	1. In the TigerVNC session in A launch a terminal emulator and   
   > ssh from it into B.   
   >   
   > 	2. At the ssh session in B created above send some graphical   
   > output to the TigerVNC session in A.   
   >   
   > 	Step two does not work - I keep getting 'Can't open display: A:   
   > 1.0'.   
   >   
   > 	I thought that the way to do pull this off consisted of executing   
   > the following commands in a terminal emulator in the TigerVNC session in   
   > A:   
   >   
   > 	$ export DISPLAY=A:1.0 $ xhost +B   
   >   
   > The thing is, this makes no difference.   
      
   > 	Any idea on how to solve this?   
      
   As Rich said, the easiest solution and the solution nowadays used in most   
   cases is probably X forwarding with ssh.   
      
   That said, if you don't want your X traffic encrypted for some reason   
   there are a number of obstacles nowadays to use X networked traffic the   
   way it used to work...   
      
   First of all: Is the X server listening on tcp port 6000 + display   
   number? By default, at least Xorg does not do that anymore unless you   
   start Xorg with the switch "-listen tcp".   
      
   Secaond: Will the X server allow the X client to connect? As Rich said,   
   "xhost +the_client" might help if you run it on the server with the   
   DISPLAY variable pointing to the local DISPLAY of that X server. However,   
   you might also have to read up on the man pages of xauth and Xsecurity.   
      
   All this trouble of allowing other machines to connect and manually   
   setting displays can be avoided with ssh X tunneling which is considered   
   a safer choice. That is probably the reason that many X servers nowadays   
   by default does not allow connections from the network.   
      
   If you on machine A is able to put a local window like "xclock" on the   
   display that you want you will be able to also get windows from machine B   
   on that display if you on machine A do:   
      
   ssh -Y B   
      
   For many X programs it will be enough to do:   
      
   ssh -X B   
      
   But some programs will not work unless you use the -Y switch instead of -   
   B.   
      
   Once logged in on machine B with the choosen command above you will find   
   that the environment variable DISPLAY already has been set. It will   
   probably be set to something like:   
      
   DISPLAY=localhost:11.0   
      
   When you start some X program like xclock it will connect to tcp port   
   localhost:6011 which is served by the sshd deamon and that will redirect   
   all X traffic through the ssh connection to machine A where it is   
   connected to the display given by the DISPLAY variable of the ssh process   
   on machine A.   
      
   For all this to work, om machine B you must make sure that sshd allows X   
   forwarding. In /etc/ssh/ssdh_config you should have the line:   
      
   X11Forwarding yes   
      
   To allways tunnel X traffic when you start the ssh client you can on   
   machine A add the following lines to /etc/ssh/ssh_config:   
      
      ForwardX11 yes   
      ForwardX11Trusted yes   
      
   The first line will be like allways starting with switch -X, also adding   
   the second line will be like allways starting with switch -Y.   
      
   The file /etc/ssh/ssh_cofig affects all users, if you don't want to do   
   that, or if you don't have root on that machine, you can also have your   
   own  ~/.ssh/config with those lines. However, to allow the ssh server to   
   accept X11 forwarding you will need root access to machine B.   
      
   If the administrator on machine B has decided not to allow X11 tunneling   
   or if you for some reason don't want to encrypt the X traffic you will   
   have to resort to the old way of tcp connections on network interfaces   
   for the unencrypted X traffic.   
      
   regards Henrik   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)