Check out the ccache setting for krb5.conf. I have mine set to ccache = FILE:/tmp/krb5cc_%u so that kerberos tickets from one session can be recognized in another session on my system.
------ Joshua A. Anderson, Ph.D. Research Area Specialist, Chemical Engineering, University of Michigan Phone: 734-647-8244 http://www-personal.umich.edu/~joaander/ On Tue, Dec 15, 2015 at 12:00 PM, Logan McNaughton <[email protected]> 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]> > 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]> 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 > >
------------------------------------------------------------------------------
_______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
