Implemented in https://github.com/TurboVNC/turbovnc/commit/eb21096ebe40b3ea1020ff6c7483422b7374b59b
On 12/15/15 4:58 PM, Logan McNaughton wrote: > Unfortunately I don't have the knowhow to create a patch for this. I'll > keep playing around with SSH + OTP. I might end up switching to using > SSSD instead of pam_krb5 for authentication. SSSD creates its own PAM > session, which solves this problem, so I might just need to look into > changing how we authenticate our users via PAM. > > On Tue, Dec 15, 2015 at 11:26 AM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > The TurboVNC session inherits any variables that were set in the shell > from which it was started, so if you SSH into the machine and run > /opt/TurboVNC/bin/vncserver, the TurboVNC session should inherit > KRB5CCNAME from that SSH session-- but of course you might be creating a > new SSH session later on, in order to tunnel the viewer. > > I am perfectly willing to accept a patch for TurboVNC that would delay > closing the PAM session until the viewer disconnects. There are some > questions in my mind as to how best to handle that, though (bearing in > mind that multiple viewers can potentially connect to the same server > session.) Maybe it is sufficient to just store the PAM handle in the > rfbClient instance for each connection. It seems like this could result > in multiple simultaneous KRB5 tickets, however. > > > On 12/15/15 11:00 AM, Logan McNaughton wrote: > > I am testing using SSH and OTP. I still run into an issue: > > > > When the SSH tunnel is created, it creates a Kerberos ticket cache > > (/tmp/krb5cc_MYUID_UyxrR0), and I can login using a OTP. > > > > However, if I do a "klist" it still doesn't know about my Kerberos > > ticket, because it doesn't know where to look for it (it defaults to > > /tmp/krb5cc_MYUID, but SSH creates the ticket with a random string on > > the end). > > > > In a normal SSH connection, an environment variable called "KRB5CCNAME" > > is set, which points to the location of the Kerberos key. I assume that > > is it not setting this variable "inside" the VNC session. > > > > Is there any way to fix this? Or is there a way to set an environment > > variable/run a script inside the VNC session upon a Viewer connection (I > > could just write a script that could figure out what KRB5CCNAME should > be)? > > > > On Mon, Dec 14, 2015 at 4:44 PM, Logan McNaughton <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > 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] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > TurboVNC-Users mailing list > > >[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > TurboVNC-Users mailing list > >[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > TurboVNC-Users mailing list > >[email protected] > <mailto:[email protected]> > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
