Interestingly, the Ubuntu/Debian implementation of pam_krb5 includes a
"retain_after_close"
option, which solves this problem:
Normally, the user’s ticket cache is destroyed when either
*pam_end()* or *pam_close_session()* is called by the authenticating
application so that ticket caches aren’t left behind after the user
logs out.
However the RHEL/CentOS pam_krb5 doesn't include this option.
On Mon, Dec 14, 2015 at 3:20 PM, Logan McNaughton <[email protected]>
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]>
> 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]
>> https://lists.sourceforge.net/lists/listinfo/turbovnc-users
>>
>
>
------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
