What you're asking is straightforward, but since it is specific to your deployment scenario, I can't do the work for free. Contact me off-list if you are interested in pursuing it as a funded development/consulting opportunity.
On 12/14/15 4:20 PM, Logan McNaughton wrote: > I understand why you need some sort of authentication to limit user > access, I thought there might be some trick though.... > > Using /etc/pam.d/sshd doesn't work, I've tried /etc/pam.d/system-auth > and some others. I am using pam_krb5 for authentication. The problem is > that when "pam_end()" is called, it destroys the Keberos tickets, > because Xvnc doesn't create a PAM "session", pam_krb5 doesn't keep the > key cache, it destroys it. > > I'm going to start playing with getting Xvnc to use xinetd and launch > GDM, I'm pretty sure as long as they are able to type their password > into GDM, it'll keep the ticket cache (because GDM creates a PAM session). > > It would be helpful if VNC (I've tried Tiger and Turbo) created a PAM > session when the used connected, and ended the session when they > disconnect, but I assume that would be a bit of work. > > On Mon, Dec 14, 2015 at 3:10 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > 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] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
