xhost not working under TigerVNC

[Harold Johanssen]

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.

I know for a fact that this works when the session in A is not a
TigerVNC one, but one run directly on a display physically attached to
the hardware where this all is running. Which makes me think that the
TigerVNC server is launched by default in such a way that what I am
trying to do is implicitly banned.

Any idea on how to solve this?

[Rich]

Post by Harold Johanssen
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.
1. In the TigerVNC session in A launch a terminal emulator and
ssh from it into B.

You are telling this ssh here to perform X forwarding, right? Or are
these systems on the same network such that B can contact A without
being carried over the ssh tunnel?

Post by Harold Johanssen
2. At the ssh session in B created above send some graphical
output to the TigerVNC session in 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
$ export DISPLAY=A:1.0
$ xhost +B

The xhost +B has to happen on A. You need to tell A "allow B to use
your display", which is what "xhost +B" does, when run on A. This
above looks like you are doing the xhost on B.

[Harold Johanssen]

Post by Rich

Post by Harold Johanssen
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.
1. In the TigerVNC session in A launch a terminal emulator and
ssh from it into B.

You are telling this ssh here to perform X forwarding, right? Or are
these systems on the same network such that B can contact A without
being carried over the ssh tunnel?

Post by Harold Johanssen
2. At the ssh session in B created above send some graphical
output to the TigerVNC session in 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
$ export DISPLAY=A:1.0 $ xhost +B

The xhost +B has to happen on A. You need to tell A "allow B to use
your display", which is what "xhost +B" does, when run on A. This above
looks like you are doing the xhost on B.

I don't think I have explained my situation properly. My
apologies. Let me try again:

Host A is running an XFCE session that was launched in A with
vncserver :1, vncserver being the TigerVNC X server.

In that session I launched an xterm, and within this xterm I
executed xhost +B, where B is the IP address if the other host involved.
Both hosts can reach each other over ssh.

In the same XFCE session in A I launched another xterm, from
which I ssh into B. Therefore in this xterm I have a shell running in B.

In this last xterm, with the shell running in B, I execute export
DISPLAY=A:1, where A is the IP address of A.

At this point I expected that when I launch an X application in
the shell running in B, its output would be displayed in the XFCE session
in A. It does not, with the diagnostic above.

The thing is, until recently I had an XFCE session running on A
directly on top of Xorg, not TigerVNC's Xvnc - and the steps above worked
as expected. It is just when I was forced to use TigerVNC (system A is
not attached to a monitor anymore) that the problem that I am describing
arose. Which is why I suspect TigerVNC is behind all this - but it does
not seem to have any options that I am aware of to get around it.

[Rich]

Post by Harold Johanssen

Post by Rich

Post by Harold Johanssen
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.
1. In the TigerVNC session in A launch a terminal emulator and
ssh from it into B.

You are telling this ssh here to perform X forwarding, right? Or are
these systems on the same network such that B can contact A without
being carried over the ssh tunnel?

Post by Harold Johanssen
2. At the ssh session in B created above send some graphical
output to the TigerVNC session in 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
$ export DISPLAY=A:1.0 $ xhost +B

The xhost +B has to happen on A. You need to tell A "allow B to use
your display", which is what "xhost +B" does, when run on A. This above
looks like you are doing the xhost on B.

I don't think I have explained my situation properly. My
Host A is running an XFCE session that was launched in A with
vncserver :1, vncserver being the TigerVNC X server.

Ok, that 'fine point' did not come across well in the original post.

Is The TigerVNC X server listening on a TCP port for remote X
connections? Because if it is not, then you can't just do "DISPLAY=*"
on B and have apps on B connect to A (because to connect to A,
something on A has to be listening on the proper TCP port on A).

Post by Harold Johanssen
In that session I launched an xterm, and within this xterm I
executed xhost +B, where B is the IP address if the other host involved.
Both hosts can reach each other over ssh.

Reaching each other over ssh does not mean they can reach each other
over X11. Nor does it mean they are on the same local network. Are
they on the same local network, or are they separated on different
networks?

Post by Harold Johanssen
At this point I expected that when I launch an X application in
the shell running in B, its output would be displayed in the XFCE session
in A. It does not, with the diagnostic above.

If the TigerVNC server does not listen for remote X connections on a
TCP port on A, then this will not work.

Instead, try using ssh X forwarding (the -X or -Y options) which tunnel
the X protocol over the ssh connection, and which cause ssh to setup
the proper DISPLAY variable on B for you automatically.

Post by Harold Johanssen
The thing is, until recently I had an XFCE session running on A
directly on top of Xorg, not TigerVNC's Xvnc - and the steps above worked
as expected.

Likely because the real xorg was listening on a TCP port for remote X
connects (usually TCP 6000). The TigerVNC server may not provide such
support at all, or it may be a CLI option to TigerVNC to cause it to
turn on "listen for external connections".

[Harold Johanssen]

Post by Rich

Post by Harold Johanssen

Post by Rich

Post by Harold Johanssen
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.
1. In the TigerVNC session in A launch a terminal emulator and
ssh from it into B.

You are telling this ssh here to perform X forwarding, right? Or are
these systems on the same network such that B can contact A without
being carried over the ssh tunnel?

Post by Harold Johanssen
2. At the ssh session in B created above send some graphical
output to the TigerVNC session in 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
$ export DISPLAY=A:1.0 $ xhost +B

The xhost +B has to happen on A. You need to tell A "allow B to use
your display", which is what "xhost +B" does, when run on A. This
above looks like you are doing the xhost on B.

I don't think I have explained my situation properly. My
Host A is running an XFCE session that was launched in A with
vncserver :1, vncserver being the TigerVNC X server.

Ok, that 'fine point' did not come across well in the original post.
Is The TigerVNC X server listening on a TCP port for remote X
connections? Because if it is not, then you can't just do "DISPLAY=*"
on B and have apps on B connect to A (because to connect to A, something
on A has to be listening on the proper TCP port on A).

It is. In fact, I can connect to it from anywhere (as long as
there is ssh conectivity) with ssvnc - which, in essence, just tunnels
vncviewer through an ssh channel.

Post by Rich

Post by Harold Johanssen
In that session I launched an xterm, and within this xterm I
executed xhost +B, where B is the IP address if the other host
involved. Both hosts can reach each other over ssh.

Reaching each other over ssh does not mean they can reach each other
over X11. Nor does it mean they are on the same local network. Are
they on the same local network, or are they separated on different
networks?

There are two cases: in the first one they are both in the same
local network, and in the second host B accesses host A through a VPN.
The behavior is the same in both cases.

Post by Rich

Post by Harold Johanssen
At this point I expected that when I launch an X application in
the shell running in B, its output would be displayed in the XFCE
session in A. It does not, with the diagnostic above.

If the TigerVNC server does not listen for remote X connections on a TCP
port on A, then this will not work.

I does.

Post by Rich
Instead, try using ssh X forwarding (the -X or -Y options) which tunnel
the X protocol over the ssh connection, and which cause ssh to setup the
proper DISPLAY variable on B for you automatically.

I tried with ForwardX11=yes in .ssh/config in both systems, to no
avail. At any rate, I had no need for that when the XFCE session in A was
launched over Xorg, rather than TigerVNC.

Post by Rich

Post by Harold Johanssen
The thing is, until recently I had an XFCE session running on A
directly on top of Xorg, not TigerVNC's Xvnc - and the steps above
worked as expected.

Likely because the real xorg was listening on a TCP port for remote X
connects (usually TCP 6000). The TigerVNC server may not provide such
support at all, or it may be a CLI option to TigerVNC to cause it to
turn on "listen for external connections".

Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are (I
believe) 5900 and above - in my case, 5901, I think. Are you saying that,
besides this, the X server (TigerVNC, in my case) must be listening on
port 6000 as well for what I am trying to do to succeed?

[Harold Johanssen]

Post by Harold Johanssen
Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are (I
believe) 5900 and above - in my case, 5901, I think. Are you saying
that, besides this, the X server (TigerVNC, in my case) must be
listening on port 6000 as well for what I am trying to do to succeed?

Actually, that may well be the problem. In B, which is running Xorg,
I get the following (among other stuff irrelevant to our purposes):

# ss -nlt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 32 0.0.0.0:5900 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:6000 0.0.0.0:*
LISTEN 0 32 [::]:5900 [::]:*
LISTEN 0 4096 [::]:6000 [::]:*

whereas in A, which is running TigerVNC, this is what I have:

State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 5 0.0.0.0:5901 0.0.0.0:*
LISTEN 0 5 [::]:5901 [::]:*

Nothing seems to be listening on port 6000.

[Rich]

Post by Harold Johanssen

Post by Harold Johanssen
Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are (I
believe) 5900 and above - in my case, 5901, I think. Are you saying
that, besides this, the X server (TigerVNC, in my case) must be
listening on port 6000 as well for what I am trying to do to succeed?

Actually, that may well be the problem. In B, which is running Xorg,
# ss -nlt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 32 0.0.0.0:5900 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:6000 0.0.0.0:*
LISTEN 0 32 [::]:5900 [::]:*
LISTEN 0 4096 [::]:6000 [::]:*
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 5 0.0.0.0:5901 0.0.0.0:*
LISTEN 0 5 [::]:5901 [::]:*
Nothing seems to be listening on port 6000.

Then you have found the cause. TigerVNC is not listening for raw xlib
TCP connections. It is only listening for vnc connections.

So, next question, does TigerVNC document an option to cause it to
listen for raw xlib connections (TCP 6000)?

[Harold Johanssen]

Post by Rich

Post by Harold Johanssen

Post by Harold Johanssen
Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are (I
believe) 5900 and above - in my case, 5901, I think. Are you saying
that, besides this, the X server (TigerVNC, in my case) must be
listening on port 6000 as well for what I am trying to do to succeed?

Actually, that may well be the problem. In B, which is running Xorg,
# ss -nlt
State Recv-Q Send-Q Local Address:Port Peer Address:Port

Process

Post by Rich

Post by Harold Johanssen
LISTEN 0 32 0.0.0.0:5900

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 4096 0.0.0.0:6000

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 32 [::]:5900

[::]:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 4096 [::]:6000

[::]:*

Post by Rich

Post by Harold Johanssen
State Recv-Q Send-Q Local Address:Port Peer Address:Port

Process

Post by Rich

Post by Harold Johanssen
LISTEN 0 5 0.0.0.0:5901

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 5 [::]:5901

[::]:*

Post by Rich

Post by Harold Johanssen
Nothing seems to be listening on port 6000.

Then you have found the cause. TigerVNC is not listening for raw xlib
TCP connections. It is only listening for vnc connections.
So, next question, does TigerVNC document an option to cause it to
listen for raw xlib connections (TCP 6000)?

Apparently not. The documentation does not say anything about it,
but, then again, it seems to be rather terse and incomplete. The Tiger
VNC forum proved to be a bit of a fiasco, with people giving advice that
seems to reveal that they know even less than I do about the subject.

Anybody aware of some other VNC framework supported under 15.0?

[Harold Johanssen]

Post by Harold Johanssen

Post by Rich

Post by Harold Johanssen

Post by Harold Johanssen
Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are

(I

Post by Rich

Post by Harold Johanssen

Post by Harold Johanssen
believe) 5900 and above - in my case, 5901, I think. Are you saying
that, besides this, the X server (TigerVNC, in my case) must be
listening on port 6000 as well for what I am trying to do to succeed?

Actually, that may well be the problem. In B, which is running

Xorg,

Post by Rich

Post by Harold Johanssen
# ss -nlt State Recv-Q Send-Q Local Address:Port Peer
Address:Port

Process

Post by Rich

Post by Harold Johanssen
LISTEN 0 32 0.0.0.0:5900

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 4096 0.0.0.0:6000

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 32 [::]:5900

[::]:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 4096 [::]:6000

[::]:*

Post by Rich

Post by Harold Johanssen
State Recv-Q Send-Q Local Address:Port Peer Address:Port

Process

Post by Rich

Post by Harold Johanssen
LISTEN 0 5 0.0.0.0:5901

0.0.0.0:*

Post by Rich

Post by Harold Johanssen
LISTEN 0 5 [::]:5901

[::]:*

Post by Rich

Post by Harold Johanssen
Nothing seems to be listening on port 6000.

Then you have found the cause. TigerVNC is not listening for raw xlib
TCP connections. It is only listening for vnc connections.
So, next question, does TigerVNC document an option to cause it to
listen for raw xlib connections (TCP 6000)?

Apparently not. The documentation does not say anything about it,
but, then again, it seems to be rather terse and incomplete. The Tiger
VNC forum proved to be a bit of a fiasco, with people giving advice that
seems to reveal that they know even less than I do about the subject.
Anybody aware of some other VNC framework supported under 15.0?

In case somebody is interested, I got some useful feedback from
the TigerVNC in the end. It turns out to be the case that one can build
TigerVNC with support to listen on port 6000 - it just so happens that
this is disable by default, and the relevant configuration option to
enable it is not used in the tigervnc.SlackBuild file found in the extra/
source/tigervnc directory shipped with 15.0.

I edited this file to add the --enable-listen-tcp option to the
big configure invocation in the second half of tigervnc.SlackBuild, and
after rebuilding, removing the currently installed version of TigerVNC,
and installing the one built as above, the resulting vncserver does
listen on port 6000, and I can do what motivated me to post my original
question.

As an aside, my feeling is that it would have been better to have
this built-in and disabled by default, while providing the capability to
enable it when launching vncserver.

Well, at least it works.

[Lew Pitcher]

Post by Harold Johanssen

Post by Harold Johanssen
Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are (I
believe) 5900 and above - in my case, 5901, I think. Are you saying
that, besides this, the X server (TigerVNC, in my case) must be
listening on port 6000 as well for what I am trying to do to succeed?

Actually, that may well be the problem. In B, which is running Xorg,
# ss -nlt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 32 0.0.0.0:5900 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:6000 0.0.0.0:*
LISTEN 0 32 [::]:5900 [::]:*
LISTEN 0 4096 [::]:6000 [::]:*
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 5 0.0.0.0:5901 0.0.0.0:*
LISTEN 0 5 [::]:5901 [::]:*
Nothing seems to be listening on port 6000.

So, we can infer that the vncserver does not use TCP/IP in it's interaction
with X11 clients (as it should use port 6000+ for those). That means that
vncserver must use an X11 "Local" connection to service that part of the
interaction. "Local" connections are often implemented as a Unix-domain
socket (akin to a pipe), and not a network connection.

This means that ssh X11 forwarding (which works by making the remote server
look like it exists on the X11 client system localhost.localnet) won't work
here.

[Henrik Carlqvist]

That means that vncserver must use an X11 "Local" connection to service
that part of the interaction. "Local" connections are often implemented
as a Unix-domain socket (akin to a pipe), and not a network connection.
This means that ssh X11 forwarding (which works by making the remote
server look like it exists on the X11 client system localhost.localnet)
won't work here.

Why not? Ssh X11 forwarding will accept X traffic on something like
localhost:11 on machine B where the sshd process accepts tcp connections
to port localhost:6011. That traffic will then be forwarded through the
ssh tunnel where the ssh process connects to DISPLAY :1 om machine A.

regards Henrik

[Lew Pitcher]

Post by Henrik Carlqvist

That means that vncserver must use an X11 "Local" connection to service
that part of the interaction. "Local" connections are often implemented
as a Unix-domain socket (akin to a pipe), and not a network connection.
This means that ssh X11 forwarding (which works by making the remote
server look like it exists on the X11 client system localhost.localnet)
won't work here.

Why not? Ssh X11 forwarding will accept X traffic on something like
localhost:11 on machine B where the sshd process accepts tcp connections
to port localhost:6011. That traffic will then be forwarded through the
ssh tunnel where the ssh process connects to DISPLAY :1 om machine A.

The X11Forwarding option transfers TCP port 6000 traffic from one end
of the ssh connection to the other. On the OP's system A, he needs an
X server that listens on TCP port 6000 to accept that forwarded traffic.
(X11Forwarding is helpful when your X server only accepts TCP connections
from localhost.localnet, and unnecessary if your X server accepts TCP
connections from other network addresses).

However, from the ss(1) dump the OP provided, the OP's X server (vncserver)
does not appear to accept traffic on port 6000, and only has open the
VNC protocol ports necessary to converse in VNC protocol with the vncviewer.

This implies that the vncserver X server /does not/ use TCP to converse
with X clients, but instead uses the X "Local" support (shared memory,
unix socket, etc). So, nothing is listening for the traffic made
"local" to localhost.localnet by ssh X11Forwarding.


At least, that's how it appears to me. Agreed that the OP's problem
is moderately complex, and I may have missed something or misunderstood
the configuration or problem.

Post by Henrik Carlqvist
regards Henrik

Regards, likewise

[Henrik Carlqvist]

Post by Lew Pitcher
This implies that the vncserver X server /does not/ use TCP to converse
with X clients, but instead uses the X "Local" support (shared memory,
unix socket, etc). So, nothing is listening for the traffic made "local"
to localhost.localnet by ssh X11Forwarding.

Ouch. Well, if so, maybe that problem can be circumvented with something
like Xnest or Xephyr running on host A.

regards Henrik

[Lew Pitcher]

Post by Henrik Carlqvist

Post by Lew Pitcher
This implies that the vncserver X server /does not/ use TCP to converse
with X clients, but instead uses the X "Local" support (shared memory,
unix socket, etc). So, nothing is listening for the traffic made "local"
to localhost.localnet by ssh X11Forwarding.

Ouch. Well, if so, maybe that problem can be circumvented with something
like Xnest or Xephyr running on host A.

Or, apparently, recompiling the vncserver X server to include TCP/IP
support :-)

Post by Henrik Carlqvist
regards Henrik

Likewise

[Harold Johanssen]

Post by Lew Pitcher

Post by Henrik Carlqvist

Post by Lew Pitcher
This implies that the vncserver X server /does not/ use TCP to
converse with X clients, but instead uses the X "Local" support
(shared memory, unix socket, etc). So, nothing is listening for the
traffic made "local"
to localhost.localnet by ssh X11Forwarding.

Ouch. Well, if so, maybe that problem can be circumvented with
something like Xnest or Xephyr running on host A.

Or, apparently, recompiling the vncserver X server to include TCP/IP
support :-)

Actually, I have just been informed that that's not necessary:
it's just a matter of editing /etc/tigervnc/vncserver-config-defaults and
adding the line

listen=tcp

which I have experimentally confirmed to be correct. It would be nice if
this could be documented more prominently (or at all) but, at the very
least, the capability is there.

[Rich]

Post by Harold Johanssen

Post by Lew Pitcher

Post by Henrik Carlqvist

Post by Lew Pitcher
This implies that the vncserver X server /does not/ use TCP to
converse with X clients, but instead uses the X "Local" support
(shared memory, unix socket, etc). So, nothing is listening for the
traffic made "local"
to localhost.localnet by ssh X11Forwarding.

Ouch. Well, if so, maybe that problem can be circumvented with
something like Xnest or Xephyr running on host A.

Or, apparently, recompiling the vncserver X server to include TCP/IP
support :-)

it's just a matter of editing /etc/tigervnc/vncserver-config-defaults and
adding the line
listen=tcp
which I have experimentally confirmed to be correct. It would be nice if
this could be documented more prominently (or at all) but, at the very
least, the capability is there.

Often, with open source programs, changes like this are the result of
users letting the developers know of the hole so it can be patched.

You might consider reporting a "documentation enhancement" item on
whatever issue tracker they use.

[Rich]

Post by Henrik Carlqvist

That means that vncserver must use an X11 "Local" connection to service
that part of the interaction. "Local" connections are often implemented
as a Unix-domain socket (akin to a pipe), and not a network connection.
This means that ssh X11 forwarding (which works by making the remote
server look like it exists on the X11 client system localhost.localnet)
won't work here.

Why not? Ssh X11 forwarding will accept X traffic on something like
localhost:11 on machine B where the sshd process accepts tcp connections
to port localhost:6011. That traffic will then be forwarded through the
ssh tunnel where the ssh process connects to DISPLAY :1 om machine A.

Ssh forwarding should work, the OP indicated it did not at first (which
is likely a missing ssh config stanza somewhere).

The OP, however, is trying to get direct X11 TCP networking running,
which means he needs something on his VNC server side listening for
those direct X11 TCP connections. Without that, his only option is
going to be getting ssh X11 forwarding working.

[Rich]

Post by Rich

I don't think I have explained my situation properly. My
Host A is running an XFCE session that was launched in A
with vncserver :1, vncserver being the TigerVNC X server.

Ok, that 'fine point' did not come across well in the original post.
Is The TigerVNC X server listening on a TCP port for remote X
connections? Because if it is not, then you can't just do
"DISPLAY=*" on B and have apps on B connect to A (because to connect
to A, something on A has to be listening on the proper TCP port on
A).

It is. In fact, I can connect to it from anywhere (as long as
there is ssh conectivity) with ssvnc - which, in essence, just
tunnels vncviewer through an ssh channel.

Connecting via vncviewer is different than a direct xlib connect. You
are trying to do native X11 xlib TCP connections, which are not
vncviwer connections. However, this does mean both systems /can/ see
each other over the network.

Post by Rich
If the TigerVNC server does not listen for remote X connections on a
TCP port on A, then this will not work.

I does.

Are you sure it is listening for xlib raw X11 TCP connections? It may
only be listening for vncviewer connects, which are not the same.

Post by Rich
Instead, try using ssh X forwarding (the -X or -Y options) which tunnel
the X protocol over the ssh connection, and which cause ssh to setup the
proper DISPLAY variable on B for you automatically.

I tried with ForwardX11=yes in .ssh/config in both systems, to no
avail. At any rate, I had no need for that when the XFCE session in A was
launched over Xorg, rather than TigerVNC.

With xorg, you had xorg listening on TCP 6000 for raw X11 xlib TCP
connections. Unless TigerVNC also listens on port 6000 for raw X11
xlib TCP connections, you'll get exactly the error message you are
seeing.

Post by Rich

The thing is, until recently I had an XFCE session running
on A directly on top of Xorg, not TigerVNC's Xvnc - and the steps
above worked as expected.

Likely because the real xorg was listening on a TCP port for remote
X connects (usually TCP 6000). The TigerVNC server may not provide
such support at all, or it may be a CLI option to TigerVNC to cause
it to turn on "listen for external connections".

Thanks. I am confused about something here thoug: when I said
above that I can vncviewer into A from B, the ports involved in A are
(I believe) 5900 and above - in my case, 5901, I think.

5900+ are the default for vnc connections.

Are you saying that, besides this, the X server (TigerVNC, in my
case) must be listening on port 6000 as well for what I am trying to
do to succeed?

Yes, the default for raw xlib network connections is TCP 6000.

[Henrik Carlqvist]

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.
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.
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
$ 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