The user ACL function only works with the PAM User/Password authentication method (which can be used with the "Plain" or "Unix Login" authentication schemes.) The user ACL is checked against the username that is submitted as part of the Plain/Unix Login auth process. There is really no way to perform that check using any other authentication scheme, because no other authentication scheme provides a username (well, OK, Ident does, but it doesn't provide a password. It's meant as a way for the viewer to interface with VNC proxies, not as a security mechanism.) If a user authenticates using a VNC password or no authentication, then the TurboVNC Server has no idea which user is attempting to connect.
It seems like the problem you're trying to solve is: how to prevent one user from connecting to another user's VNC session, but without using authentication. And hopefully when I phrase it that way, you'll realize why it's impossible. The VNC session has to be authenticated somehow, because that's the only way to restrict access to it. You can use no authentication along with SSH tunneling, and you can restrict connections to localhost (thus forcing all connections to be made through SSH.) However, this doesn't prevent user1 from connecting to user2's VNC session, as long as both user1 and user2 have a valid account on the server. I know we have some deployments that are using SSH, so hopefully one of those SysAdmins can chime in with more information regarding how they implement user isolation in such an environment (assuming they do.) At the moment, the only way I know how to do this without requiring the user to log in twice is to use a one-time password. For instance, if you're deploying the viewer from a portal, then the portal can generate an OTP on the TurboVNC Server, then it can pass that OTP to the Java viewer via a .jnlp (Java Web Start) file, or it can create a .vnc connection profile on the fly, pass the OTP in that profile, and download it to the client machine, where it will be opened in the standalone TurboVNC Viewer. Basically, the portal controls user isolation, because the users have to log into the portal using their Unix login credentials. The portal then exposes only the user's running sessions, allowing them to generate on-the-fly OTPs and connect only to those sessions. In order to really limit the Xvnc instances on a per-user basis without using (additional) authentication, it would be necessary for the TurboVNC Server to more tightly integrate with the SSH server-- probably requiring some sort of scheme whereby the remote end of the SSH tunnel can automatically pass authentication credentials to the VNC server, or whereby the VNC server can use an existing Kerberos ticket. But as far as why the Plain authentication scheme isn't generating Kerberos tickets, have you tried using a different value for pam-service-name? The default PAM service we use (/etc/pam.d/turbovnc) probably isn't creating the necessary tickets, but if you use "pam-service-name = sshd", for instance, I'll bet that it would. On 12/14/15 2:00 PM, Logan McNaughton wrote: > Here is my situation: > > My current users login to the :0 display using a different remote > desktop product. They are presented with the GDM login when they open a > session. > > When they login (authenticated using Kerberos) they are given a Kerberos > ticket, which allows them to SSH to other machines in our environment > without a password. > > I am creating a VNC launcher, (the "vncserver" command is run for the > user when they click "launch" for a machine in a list) > > When using VNC "Plain" authentication, they can authenticate via > Kerberos, but they aren't given a ticket (I presume it is because > Xserver/VNC doesn't create a session). > > I can get around this by connecting via an SSH tunnel, when I do that, > the SSH session creates the Kerberos ticket. Problem solved, almost. > > If I use an SSH tunnel and "Plain", they are prompted for their > username/password to SSH into the machine, and then again for the > "Plain" authentication. > > I want to be able to use an SSH tunnel + "None" authentication, and > limit the users that can connect to the session to only the user that > owns the "Xvnc" process. Is there any way to do this? enable-user-acl is > only respected if you use "Password" or "Plain" authentication. ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
