- REMINNA VNC THROUGH SSH FAILED TO BIND ON LOCAL PORT INSTALL
- REMINNA VNC THROUGH SSH FAILED TO BIND ON LOCAL PORT FULL
There are endless possibilities you could hack together with stdio over SSH.
REMINNA VNC THROUGH SSH FAILED TO BIND ON LOCAL PORT INSTALL
You could have a single entry point to an internal network where you might run VNC servers on TCP ports and you would avoid the extra setup of having to configure port forwarding for each and every host you could connect to - just install the friendly VNC helper on the entry server or use netcat as the helper directly by executing it instead. The third option of using it to proxy to another host on the same network could also be handy. It helps secure the session on your local system as you then don't have a loopback TCP socket listening for connections. The second option of connecting to a local TCP socket solves the port forwarding hack you need to do with SSH. For example I could launch the default GNOME session on EL7 remotely without running an insecure VNC TCP server on localhost exposing it to other users. The first option to run xinit session (persistently or closing on disconnect) is the one that I personally like to use on a server if I want to run some GUI utilities on it.
This design relies on client implementation in vncviewer with libssh2 that can execute the helper program on the server to do some proxying for it. VNC over SSH solved this problem by using the exec channel of SSH as a secure transport of VNC data.
REMINNA VNC THROUGH SSH FAILED TO BIND ON LOCAL PORT FULL
Running applications and full X sessions remotely on a headless system that has Xvnc installed is somewhat complex and insecure usually glued together with port forwarding to localhost. This also contains a more complete design. The UNIX socket issue became a playground for my VNC over SSH design so I've moved the discussion to its own issue.