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