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]>> 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]>> 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]>>> 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]>> > >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
