How can I find the mapping on `$DISPLAY` after `ssh -X`?

Question

On machine B, I remote access machine C

$ ssh -X t@C
$ echo $DISPLAY
localhost:10.0

How can I find/verify the mapping of $DISPLAY on C to $DISPLAY on B? Can it be done by the following command on C?

$ netstat -a | grep 6010
tcp        0      0 localhost:6010          0.0.0.0:*               LISTEN     
tcp6       0      0 ip6-localhost:6010      [::]:*                  LISTEN 

Why is the connection between $DISPLAY on C and $DISPLAY on B LISTEN not ESTABLISHED, given that the X forwarding channel has been created?

When I run a X client on C, how can I verify that it is connected to the X server on B (the local machine)? Why do I get more information about port 6010 in the following than before running the X client?

$ eog &
[1] 1129
$ netstat -a | grep 6010
tcp        0      0 localhost:6010          0.0.0.0:*               LISTEN     
tcp        0      0 localhost:59782         localhost:6010          TIME_WAIT  
tcp        0      0 localhost:59780         localhost:6010          ESTABLISHED
tcp        0      0 localhost:59778         localhost:6010          TIME_WAIT  
tcp        0      0 localhost:6010          localhost:59780         ESTABLISHED
tcp6       0      0 ip6-localhost:6010      [::]:*                  LISTEN

Thanks.

Answer 1

"the mapping of $DISPLAY on C to $DISPLAY on B" what does that mean?

Clearly you grep out of something on C, so you only see sockets on C which involves "port num=6010". Other connection or listening socket on C are grep out.

You didn't see any connection before because there hasn't been any X client running and connected to sshd(port number=6010), and more info after because you now run an X client, which has connected to your sshd(port num=6010).

You have to know the network topology when using SSH tunnel. SSH server on C opens a new socket which listen on port 6010 because it was asked to by the SSH client on B. The ssh tunnel is still established between SSH client on B and SSH server on C(port num=22, if sshd not specially configured), you don't see this tunnel connection since you grep it out. X clients on C connects to sshd(port number=6010), then sshd multiplex these connections using the ssh tunnel and forward these connections to the X server on B.

"Connection between $DISPLAY on C and $DISPLAY on B" doesn't really exist, the ssh tunnel is created between C:22 and address_of_the_SSH_client_on_B. And since it's a connection, it's not possible in the LISTENING state.

use netstat -ap without grep to see more information.

All the connection we mentioned in this answer means real TCP connection, from the kernel's view, not "connections" from end-users' view.

Answer 2

Why is the connection between $DISPLAY on C and $DISPLAY on B LISTEN not ESTABLISHED, given that the X forwarding channel has been created?

The X forwarding channel has not been yet created. It's only created when a client connects to the port 6010 on your C (remote) machine. The connection will be forwarded as a separate channel through the ssh connection (not through a different tcp connection between C and B). To display all the channels forwarded through an ssh connection, you should use the ~# escape at the beginning of a line:

$ ssh -X localhost
$ ~#
The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)
$ netstat | grep 6010

$ xterm &
$ ~#
The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)
  #1 x11 (t4 r3 i0/0 o0/0 fd 8/8 cc -1)
$ netstat | grep 6010
tcp6       0      0 localhost:6010          localhost:39698         ESTABLISHED
tcp6       0      0 localhost:39698         localhost:6010          ESTABLISHED

When I run a X client on C, how can I verify that it is connected to the X server on B (the local machine)?

I don't know any straighforward way to check that. I don't know about any X11 core protocol or extension request that returns the machine the X11 server runs on. You should do it step by step: first check if the X11 client is connected to a forwarder, then where it is forwarding the connection, etc.