Unfortunately I don't have any funding available to me, I'm going to have to play with this a bit more On Dec 14, 2015 4:12 PM, "DRC" <[email protected]> wrote:
> 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 >
------------------------------------------------------------------------------
_______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
