I tried that, but for some reason the krb5cc_%u file is owned by root:root, I'm not sure why it's doing that, when the file is krb5cc_%u_XXXXX it is owned by the user like it should be
On Tue, Dec 15, 2015 at 10:48 AM, Joshua Anderson <[email protected]> wrote: > 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 > >
------------------------------------------------------------------------------
_______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
