vnc-ltsp-config with TurboVNC

This is the continuation of the issue #271

In the future, please continue the discussion under the same issue rather than starting a new issue.

Following your response to my last message, I made the recommended changes but I can no longer even connect on client machine. Above are the configuration steps:

1- I installed VirtualGL-2.5.2-1.el7 2- I installed turbovnc-2.2.1-20190102 3- I installed vnc-ltsp-config-4.0-4.el5 (when installing, the dependence vnc-server => 4.0 is required, but I forced with --nodeps) 4- I followed the configuration of #271

I tested it myself on CentOS 7.9, so I know it works. I was, of course, using the latest stable releases of VirtualGL and TurboVNC, which are 2.6.5 and 2.2.6. Those are available in the official YUM repositories provided by The VirtualGL Project. (VirtualGL 2.5.2 is nearly four years old.) There are quite a few bug fixes in the latest versions relative to the versions you tested. I don't know if any of those bug fixes affects this configuration, but they might. I also did not force-install the vnc-ltsp-config RPM. I just let it install the TigerVNC Server, as it wanted to do. I don't know if that matters. Also, you may have to restart both xinetd and vncts in order for all of the configuration changes to take effect.

After this, when trying on client machine to connect (with IP adress), i have After 126 sec, it closes

In /var/log/messages, no message error between the START and the EXIT of the vnc to help determine the cause

I have also the following message that i don't know if it has any link with the problem

Any idea? Any help?

No ideas. Sorry. I verified that it works for me and posted the exact procedure I used, but even Red Hat doesn't support the LTSP approach anymore, so there is a limit to what I can do. If you want to pay for my time, I'm happy to log into your machine remotely and diagnose the issue, but I don't think I have any special knowledge of this system. I just followed the instructions you posted in the other thread and modified them accordingly for TurboVNC.

Concerning the TurboVNC Session Manager, will this allow us to do what we want (i.e. configure a multi-gui session for a user)?

I don't know what you mean by "multi-GUI", so let's define some terms. A TurboVNC "session" is an instance of the TurboVNC Server (Xvnc) that runs under a particular user account and uses a particular X11 display (:1, :2, etc.) and a particular RFB port (5901, 5902, etc.) X11 applications talk to the X display, and VNC viewers talk to the RFB port. Each TurboVNC session is a virtual X server that is independent of all other TurboVNC sessions, so you can launch multiple TurboVNC sessions under the same user account if you wish, and you can launch multiple TurboVNC sessions on the same machine under different user accounts if you wish. That aspect of the TurboVNC Server has nothing to do with LTSP or the TurboVNC Session Manager. LTSP or the TurboVNC Session Manager are just front ends. The LTSP approach allows multiple users to log into a specific TurboVNC session, but in order to do that, you have to open up security holes in the server. My point is: given that TurboVNC is inherently a multi-session solution, there is no need for multiple users to share the same TurboVNC session. Each user can have their own session, which eliminates the need to use the LTSP approach and thus eliminates those security holes. However, with each user having their own session, there are a few usability issues that have to be addressed:

How can users start and stop sessions without logging into the server with SSH and using the command line?
How can users know which display number/RFB port their session is using, so they can straightforwardly connect to it with the TurboVNC Viewer?
How can users straightforwardly log into the session and ensure that their connection to it is secure?

You could accomplish all of that manually without the TurboVNC Session Manager, or you could create a web portal around TurboVNC (which is what most large organizations have done in order to deploy TurboVNC), but the TurboVNC Session Manager automates all of it. With the TurboVNC Session Manager, the TurboVNC Viewer connects to the TurboVNC host using its internal SSH client (which fully supports both OpenSSH config files and password-less login using ssh-agent or Pageant.) Once the user has successfully authenticated with the host using SSH, the TurboVNC Viewer leaves that SSH session open and uses it to start a new TurboVNC session for the user, if one hasn't already been started, or to provide a dialog listing all of the user's running TurboVNC sessions, thus allowing the user to connect to one of them or shut it down remotely. When connecting to a TurboVNC session, the TurboVNC Session Manager automatically creates a one-time password (OTP) for the session and passes it over the SSH tunnel to the viewer, which uses it to authenticate with the session. Thus, from the user's point of view, once they have successfully authenticated with SSH, they don't have to authenticate again. Also, the TurboVNC Session Manager automatically tunnels the connection through the established SSH session, so the connection is encrypted by default.

This is certainly a lot more secure than the LTSP approach, and it's also more flexible, since you don't need to use the same TurboVNC session for multiple users. Each user can dynamically control their own dedicated TurboVNC sessions. Effectively, the job of the display manager-- authentication and X session control-- is now handled remotely. This is as opposed to the LTSP approach, which runs the display manager inside of the TurboVNC session.

TurboVNC / turbovnc

vnc-ltsp-config with TurboVNC #277