Proposed enhancements to the TurboVNC Session Manager

[dcommander]

This is another one of those issues that I post in order to try to elicit ideas for funded development.

Proposals for enhancing the TurboVNC Session Manager

Handle separate gateway and VNC host

The TurboVNC Session Manager currently only supports simple deployment scenarios-- scenarios in which the TurboVNC host and SSH gateway are the same machine. It is conceivable that it could be extended to work like the -via option, whereby the viewer connects to the SSH gateway and then uses it to connect to the TurboVNC host. This would, however, require some effort (and funding), and it's the sort of project on which I would want to work closely with an organization that could actively test the feature.

Handle external SSH clients

It is also conceivable that the TurboVNC Session Manager could be extended to support external SSH clients, which might be beneficial for certain organizations (I'm thinking mainly of organizations that use Kerberos or another SSH authentication mechanism that our embedded SSH client doesn't support.)

Support sessions that are listening on Unix domain sockets

This is straightforward but would require extending the TurboVNC Session Manager protocol so that vncserver -sessionstart and vncserver -sessionlist report both the X display of the session as well as its Unix domain socket path. The TurboVNC Session Manager would need both pieces of information in order to successfully generate an OTP for and connect to a session that is listening on a UDS. Since UDS support requires an external SSH client, this item depends on the item above.

Provide additional session information

Referring to #211, it should be possible for the Session Manager to determine information about the TurboVNC sessions (such as uptime and number of viewers connected) that might help distinguish them. The uptime information could be determined by parsing /proc in the vncserver script. Connected session information could be stored by the RFB server using an X atom, which could be read by the vncserver script.

Better noVNC integration

This may not be very important, because if someone is using the TurboVNC Session Manager, they probably aren't using noVNC. However, it would be nice-- for collaboration purposes-- if the Session Manager could parse the output of the vncserver script to determine the noVNC URL, generate a new OTP for the session, append the OTP to the noVNC URL, and provide a dialog box with a hot link to launch the client-side browser and point it to that URL (or copy the URL to the clipboard.) That would allow a TurboVNC user to very easily share their session with a colleague who doesn't normally use TurboVNC.

Admin interface

Conceivably, a set of scripts could be developed that wrap sudo and vncserver in order to make it easy for a SysAdmin to manage all TurboVNC sessions running on the host. These scripts need not necessarily be part of the TurboVNC package itself.

[gdevenyi]

Following up on #393, a great enhancement to the Session Manager would be to fully support ProxyCommand/ProxyJump in the vncviewer configuration, that is, to ssh into a host behind another ssh host and launch vncserver. Currently I use x2go to do this which has a full proxy configuration:

[dcommander]

#393 (comment)

[dcommander]

Two basic problems with implementing external SSH client support in the Session Manager:

1. The need to create a unique control socket for each unique Session Manager connection. The tokens used in the control socket path would effectively only allow for one control socket per client/host pair, not one control socket per connection. It would probably be necessary to create a control socket path based on the TurboVNC Viewer process ID and some sort of connection instance hash (perhaps based on the instance of the CConn class.)
2. The need to keep the control socket open indefinitely while the user selects a session in the Session Manager dialog. We would need to be careful about explicitly cleaning up the control socket (by issuing {ssh} -o ControlPath={control_socket_path} -O exit {host} if the user closes the dialog without connecting, when the user disconnects the session, or if the viewer aborts for any reason.

Frankly, that system seems more fragile than I would prefer.