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
