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]> 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] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users >
------------------------------------------------------------------------------
_______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
