Figure out how to run via SSH tunnel

[fedorov]

Opening a firewall port for everyone to connect is not an option for a system that hosts restricted data. A more appropriate approach is to use SSH tunnel for VNC connection. With GCP, tunnel can be established like this (see article on the topic here):

$ gcloud compute ssh <instance_name> --project <project_name> -- -L 5900:localhost:5900

To test this approach, I believe x11vnc needs to run with the -localhost option to allow connection from local host.

To simplify troubleshooting, VNC connection can be tested directly. On mac, this can be done with the following:

$ open vnc://localhost:5900

However, something is not quite right when I try to do this, since it stays in "Connecting..." mode. Log messages on the server side (note the timestamps):

08/07/2019 21:15:25 Got connection from client 127.0.0.1
08/07/2019 21:15:25   other clients:
08/07/2019 21:15:25 Normal socket connection
08/07/2019 21:15:25 check_access: checking against full string "127.0.0.1"
08/07/2019 21:15:25 check_access: client 127.0.0.1 fullmatch matches host 127.0.0.1
08/07/2019 21:15:25 Disabled X server key autorepeat.
08/07/2019 21:15:25   to force back on run: 'xset r on' (3 times)
08/07/2019 21:15:25 incr accepted_client=1 for 127.0.0.1:46408  sock=11
08/07/2019 21:15:25 Client Protocol Version 3.3
08/07/2019 21:15:25 Protocol version sent 3.3, using 3.3
08/07/2019 21:15:31 rfbProcessClientInitMessage: client gone
08/07/2019 21:15:31 client_count: 0
08/07/2019 21:15:31 Restored X server key autorepeat to: 1
08/07/2019 21:15:31 Client 127.0.0.1 gone
08/07/2019 21:15:31 Statistics             events    Transmit/ RawEquiv ( saved)
08/07/2019 21:15:31  TOTALS              :      0 |         0/        0 (  0.0%)
08/07/2019 21:15:31 Statistics             events    Received/ RawEquiv ( saved)
08/07/2019 21:15:31  TOTALS              :      0 |         0/        0 (  0.0%)
08/07/2019 21:15:32 Got connection from client 127.0.0.1
08/07/2019 21:15:32   other clients:
08/07/2019 21:15:32 Normal socket connection
08/07/2019 21:15:32 check_access: checking against full string "127.0.0.1"
08/07/2019 21:15:32 check_access: client 127.0.0.1 fullmatch matches host 127.0.0.1
08/07/2019 21:15:32 Disabled X server key autorepeat.
08/07/2019 21:15:32   to force back on run: 'xset r on' (3 times)
08/07/2019 21:15:32 incr accepted_client=2 for 127.0.0.1:46412  sock=11
08/07/2019 21:15:32 Client Protocol Version 3.3
08/07/2019 21:15:32 Protocol version sent 3.3, using 3.3
08/07/2019 21:15:48 cutbuffer_send: no send: uninitialized clients
08/07/2019 21:16:18 created selwin: 0x600018
08/07/2019 21:16:18 called initialize_xfixes()
08/07/2019 21:17:52 copy_tiles: allocating first_line at size 21
08/07/2019 21:20:35 idle keyboard:   turning X autorepeat back on.

Seems like the connection is getting through, but at the moment I do not know why it is not succeeding on the client side.

@pieper any thoughts?

[fedorov]

I realized that on the client the password I needed to enter was not my desktop password, but server password (and I don't know what it is). I realized this while following instructions here: https://medium.com/google-cloud/linux-gui-on-the-google-cloud-platform-800719ab27c5, which use vncserver, which in turn prompts to create a password on startup. Once I created it, connection with open vnc://... succeeds.

[fedorov]

I am still unable to connect when I start vnc with x11vnc -forever -localhost - the log messages look the same as before on the server side.

[fedorov]

But going back to vncserver, it seems to work!

http://localhost:6080/vnc.html?host=localhost&port=6080

I will add a section to the instructions.

[fedorov]

Realizing now that vncserver is using xvnc, which combines X and VNC together, and is NOT GLX capable, so I am back to square one - need to figure out why x11vnc is not working for me ... :-(

[fedorov]

Mandatory reading that I just now found: http://www.karlrunge.com/x11vnc/index.html#tunnelling

[pieper]

Yes, you could do that. Note that in his example he starts x11vnc via ssh, but that assumes there is already an X server running. If you already have it running you could just use ssh to open a shell and also tunnel the port you want.

[fedorov]

I managed to get 5900 open in the firewall, and I still cannot establish VNC connection, so something else must be wrong with my setup, it may not be about SSH tunnel.

[fedorov]

Resolved in 7d3691e18cf4c3411a569d19e3d079c03507303d

The main culprit to the above was that the stock VNC client that comes up with macOS is apparently NOT suitable for testing VNC connection in this situation. It was confirmed that this open source VNC client was working under the same conditions where open vnc://... would not be able to establish a connection.