KEYRING:persistent and ssh

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

KEYRING:persistent and ssh

t Seeger
Hello,

i have a little problem with the 'KRB5CCNAME' environment variable. I set
the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
this is not very nice.
Did anyone had a similar problem and found a solution?

Many thanks in advance and best regards
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Benjamin Kaduk-2
On Fri, 16 Sep 2016, t Seeger wrote:

> Hello,
>
> i have a little problem with the 'KRB5CCNAME' environment variable. I set
> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
> set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
> to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
> this is not very nice.
> Did anyone had a similar problem and found a solution?

The KRB5CCNAME environment variable takes precedence over the default
ccache name.  It sounds like you should check the system dotfiles for a
KRB5CCNAME assignment and check whether pam_krb5 is doing anything
special.

-Ben
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

t Seeger
Hello,

i grep for KRB5CCNAME to the etc directory and the only match is in
"/etc/default/slapd" and this is ok and has nothing todo with the login
process. I think the sshd daemon do not honor the "default_ccache_name"
and uses the default file format. I use pam_sss instead of pam_krb5. If
i get my internet connection up again i will post my configuration files.

Thanks and best regards

On 19.09.2016 06:11, Benjamin Kaduk wrote:

> On Fri, 16 Sep 2016, t Seeger wrote:
>
>> Hello,
>>
>> i have a little problem with the 'KRB5CCNAME' environment variable. I set
>> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
>> set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
>> to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
>> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
>> this is not very nice.
>> Did anyone had a similar problem and found a solution?
> The KRB5CCNAME environment variable takes precedence over the default
> ccache name.  It sounds like you should check the system dotfiles for a
> KRB5CCNAME assignment and check whether pam_krb5 is doing anything
> special.
>
> -Ben


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Russ Allbery-2
tseegerkrb <[hidden email]> writes:

> I think the sshd daemon do not honor the "default_ccache_name" and uses
> the default file format.

I'm pretty sure you're correct if you're doing GSS-API authentication with
ssh.  Looking at the source code to sshd, you don't seem to get much
choice in the matter:

# ifdef HAVE_KRB5_CC_NEW_UNIQUE
        problem = krb5_cc_new_unique(authctxt->krb5_ctx,
             krb5_fcc_ops.prefix, NULL, &authctxt->krb5_fwd_ccache);
# else
        problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_fcc_ops,
            &authctxt->krb5_fwd_ccache);
# endif

[...]

        authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache);

        len = strlen(authctxt->krb5_ticket_file) + 6;
        authctxt->krb5_ccname = xmalloc(len);
#ifdef USE_CCAPI
        snprintf(authctxt->krb5_ccname, len, "API:%s",
            authctxt->krb5_ticket_file);
#else
        snprintf(authctxt->krb5_ccname, len, "FILE:%s",
            authctxt->krb5_ticket_file);
#endif

You'd need to write a PAM module that read in that ticket cache file and
wrote it back out to your preferred ticket cache format and then adjusted
KRB5CCNAME in the user's environment.  Unfortunately, there doesn't appear
to be any way of preventing the ticket cache from being temporarily
written to /tmp.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

t Seeger
Thanks for your help. Is my setup so special
(kerberos/OpenLDAP/sssd/sshd) nobody using it? I think i will ask
debian/ubuntu or the openssh maintainer for help.


On 19.09.2016 18:23, Russ Allbery wrote:

> tseegerkrb <[hidden email]> writes:
>
>> I think the sshd daemon do not honor the "default_ccache_name" and uses
>> the default file format.
> I'm pretty sure you're correct if you're doing GSS-API authentication with
> ssh.  Looking at the source code to sshd, you don't seem to get much
> choice in the matter:
>
> # ifdef HAVE_KRB5_CC_NEW_UNIQUE
>          problem = krb5_cc_new_unique(authctxt->krb5_ctx,
>               krb5_fcc_ops.prefix, NULL, &authctxt->krb5_fwd_ccache);
> # else
>          problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_fcc_ops,
>              &authctxt->krb5_fwd_ccache);
> # endif
>
> [...]
>
>          authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache);
>
>          len = strlen(authctxt->krb5_ticket_file) + 6;
>          authctxt->krb5_ccname = xmalloc(len);
> #ifdef USE_CCAPI
>          snprintf(authctxt->krb5_ccname, len, "API:%s",
>              authctxt->krb5_ticket_file);
> #else
>          snprintf(authctxt->krb5_ccname, len, "FILE:%s",
>              authctxt->krb5_ticket_file);
> #endif
>
> You'd need to write a PAM module that read in that ticket cache file and
> wrote it back out to your preferred ticket cache format and then adjusted
> KRB5CCNAME in the user's environment.  Unfortunately, there doesn't appear
> to be any way of preventing the ticket cache from being temporarily
> written to /tmp.
>

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Russ Allbery-2
tseegerkrb <[hidden email]> writes:

> Thanks for your help. Is my setup so special (kerberos/OpenLDAP/sssd/sshd)
> nobody using it? I think i will ask debian/ubuntu or the openssh
> maintainer for help.

It's sadly quite unusual to use non-FILE ticket caches.  I wish it
weren't, since KEYRING has nice security properties, but it's relatively
new and the rest of the world has definitely not adapted yet.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

t Seeger
On 21.09.2016 20:03, Russ Allbery wrote:
> tseegerkrb <[hidden email]> writes:
>
>> Thanks for your help. Is my setup so special (kerberos/OpenLDAP/sssd/sshd)
>> nobody using it? I think i will ask debian/ubuntu or the openssh
>> maintainer for help.
> It's sadly quite unusual to use non-FILE ticket caches.  I wish it
> weren't, since KEYRING has nice security properties, but it's relatively
> new and the rest of the world has definitely not adapted yet.
>
Maybe i got an other problem cause if i connect from a client without a
ticket i get (after i enter my password)  a ticket and it use the
KEYRING:persistent cache. KRB5CCNAME is set to the KEYRING:persistent
and i can ssh to the next box without entering my password again, but
then it use the file based ticket cache...

An other problem is that i can not use user@REALM to ssh to the next box
without a password. If use "kinit user@REALM" i get a ticket, but if i
then "ssh -l user@REALM mybox" it ask for the password again. But if i
just use "ssh -l user mybox" it connects without the password.

Any idea where i should search for the failure?


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Tina Harriott
In reply to this post by t Seeger
On 16 September 2016 at 16:02, t Seeger <[hidden email]> wrote:

> Hello,
>
> i have a little problem with the 'KRB5CCNAME' environment variable. I set
> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
> set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
> to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
> this is not very nice.
> Did anyone had a similar problem and found a solution?
>
> Many thanks in advance and best regards
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

FYI KEYRING: will be removed in future versions of Linux kernel
because of the ongoing design defects.
Also, KEYRING is not secure, under certain scenarios (DOCKER&et al)
unrelated users/uids can obtain the secure data.

Tina
--
Tina Harriott  - Women in Mathematics
Contact: [hidden email]
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Roland C. Dowdeswell
In reply to this post by t Seeger
On Tue, Sep 27, 2016 at 09:40:45AM +0200, tseegerkrb wrote:
>

> An other problem is that i can not use user@REALM to ssh to the next box
> without a password. If use "kinit user@REALM" i get a ticket, but if i
> then "ssh -l user@REALM mybox" it ask for the password again. But if i
> just use "ssh -l user mybox" it connects without the password.
>
> Any idea where i should search for the failure?

Your account on the other box is likely "user" not "user@REALM".
What's in /etc/passwd?  If it is "user:..." then the account's name
is "user" and you must use "-l user".  It's prompting you for a
password on the other host because your login has failed because
the username doesn't match an existing user on the system.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

t Seeger
In reply to this post by Tina Harriott
> On 27 Sep 2016, at 15:20, Tina Harriott <[hidden email]> wrote:
>
>> On 16 September 2016 at 16:02, t Seeger <[hidden email]> wrote:
>> Hello,
>>
>> i have a little problem with the 'KRB5CCNAME' environment variable. I set
>> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
>> set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
>> to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
>> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
>> this is not very nice.
>> Did anyone had a similar problem and found a solution?
>>
>> Many thanks in advance and best regards
>> ________________________________________________
>> Kerberos mailing list           [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>
> FYI KEYRING: will be removed in future versions of Linux kernel
> because of the ongoing design defects.
> Also, KEYRING is not secure, under certain scenarios (DOCKER&et al)
> unrelated users/uids can obtain the secure data.
>
> Tina
> --
> Tina Harriott  - Women in Mathematics
> Contact: [hidden email]

Thank you for your replay. I have two questions. First can you tell me what is the best practice way to store the credential cache and second where can I find more informations about the plan to remove the KEYRING from the kernel?

Thorsten
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Simo Sorce-3
In reply to this post by Tina Harriott
On Tue, 2016-09-27 at 15:20 +0200, Tina Harriott wrote:

> On 16 September 2016 at 16:02, t Seeger <[hidden email]> wrote:
> > Hello,
> >
> > i have a little problem with the 'KRB5CCNAME' environment variable. I set
> > the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
> > set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
> > to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
> > I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
> > this is not very nice.
> > Did anyone had a similar problem and found a solution?
> >
> > Many thanks in advance and best regards
> > ________________________________________________
> > Kerberos mailing list           [hidden email]
> > https://mailman.mit.edu/mailman/listinfo/kerberos
>
> FYI KEYRING: will be removed in future versions of Linux kernel
> because of the ongoing design defects.

Could you please provide the source of this rumor ?
As far as I know this statement is false.

> Also, KEYRING is not secure, under certain scenarios (DOCKER&et al)
> unrelated users/uids can obtain the secure data.

We are working upstream to properly namespace the keyring too, once done
the container's case will be addressed too.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Lionel Cons
In reply to this post by t Seeger
Storing: Simply on a ram filesystem and use ACLS to tackle it down to
the list of users who need it. This is pretty much what KEYRING does,
with a custom nonstandard api.

FYI by policy CERN has forbidden the use of Linux KEYRING because of
several security breaches (info bleeds through chroot&co) and mostly
have patched the kernel to just issue a errno not supported if someone
tries to use Linux KEYRING).

Lionel

On 28 September 2016 at 13:42, t Seeger <[hidden email]> wrote:

>> On 27 Sep 2016, at 15:20, Tina Harriott <[hidden email]> wrote:
>>
>>> On 16 September 2016 at 16:02, t Seeger <[hidden email]> wrote:
>>> Hello,
>>>
>>> i have a little problem with the 'KRB5CCNAME' environment variable. I set
>>> the default_ccache_name to KEYRING:persistent:%{uid} but if i login it is
>>> set to "file:/tmp/krb5cc_${uid}_XXXXXXXXXX" cause ssh sets the KRB5CCNAME
>>> to file:/tmp/krb5cc_${uid}_XXXXXXXXXX...
>>> I found a workaround with adding "unset KRB5CCNAME" to /etc/bash.bashrc but
>>> this is not very nice.
>>> Did anyone had a similar problem and found a solution?
>>>
>>> Many thanks in advance and best regards
>>> ________________________________________________
>>> Kerberos mailing list           [hidden email]
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>> FYI KEYRING: will be removed in future versions of Linux kernel
>> because of the ongoing design defects.
>> Also, KEYRING is not secure, under certain scenarios (DOCKER&et al)
>> unrelated users/uids can obtain the secure data.
>>
>> Tina
>> --
>> Tina Harriott  - Women in Mathematics
>> Contact: [hidden email]
>
> Thank you for your replay. I have two questions. First can you tell me what is the best practice way to store the credential cache and second where can I find more informations about the plan to remove the KEYRING from the kernel?
>
> Thorsten
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos



--
Lionel
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Ken Hornstein
>Storing: Simply on a ram filesystem and use ACLS to tackle it down to
>the list of users who need it. This is pretty much what KEYRING does,
>with a custom nonstandard api.

FWIW, we are going to KEYRING everywhere; the semantics for what you
want in terms of a credential cache store are almost perfect.  What you
DON'T want to do is store credentials on a filesystem (be it in RAM or
on spinning disk); been there, done that.  As for the leaking of information
across chroot/Docker containers ... I'm trying to imagine how that would
be an actual security problem in practice.  I could be proven wrong, of
course, but I'd like to see some more concrete risks here.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Simo Sorce-3
On Wed, 2016-09-28 at 11:43 -0400, Ken Hornstein wrote:

> >Storing: Simply on a ram filesystem and use ACLS to tackle it down to
> >the list of users who need it. This is pretty much what KEYRING does,
> >with a custom nonstandard api.
>
> FWIW, we are going to KEYRING everywhere; the semantics for what you
> want in terms of a credential cache store are almost perfect.  What you
> DON'T want to do is store credentials on a filesystem (be it in RAM or
> on spinning disk); been there, done that.  As for the leaking of information
> across chroot/Docker containers ... I'm trying to imagine how that would
> be an actual security problem in practice.  I could be proven wrong, of
> course, but I'd like to see some more concrete risks here.

It becomes a potential security issue if you run containers as root, but
nobody is doing that in production, right ? Because if you do, the
keyring issue is not the major problem here.

Besides there are various part of the kernel that depends on the keyring
now, disabling it is going to cause hard to diagnose issues or limit the
features you can use.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Cedric Blancher
On 28 September 2016 at 19:01, Simo Sorce <[hidden email]> wrote:

> On Wed, 2016-09-28 at 11:43 -0400, Ken Hornstein wrote:
>> >Storing: Simply on a ram filesystem and use ACLS to tackle it down to
>> >the list of users who need it. This is pretty much what KEYRING does,
>> >with a custom nonstandard api.
>>
>> FWIW, we are going to KEYRING everywhere; the semantics for what you
>> want in terms of a credential cache store are almost perfect.  What you
>> DON'T want to do is store credentials on a filesystem (be it in RAM or
>> on spinning disk); been there, done that.  As for the leaking of information
>> across chroot/Docker containers ... I'm trying to imagine how that would
>> be an actual security problem in practice.  I could be proven wrong, of
>> course, but I'd like to see some more concrete risks here.
>
> It becomes a potential security issue if you run containers as root, but
> nobody is doing that in production, right ? Because if you do, the
> keyring issue is not the major problem here.
>
> Besides there are various part of the kernel that depends on the keyring
> now, disabling it is going to cause hard to diagnose issues or limit the
> features you can use.

That's hard to believe now that AWS and Google clouds have keyring
support patched out of their kernels (SEL at least), too. Syscalls are
still there but they all return not supported.

Ced
--
Cedric Blancher <[hidden email]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Simo Sorce-3
On Wed, 2016-09-28 at 22:17 +0200, Cedric Blancher wrote:

> On 28 September 2016 at 19:01, Simo Sorce <[hidden email]> wrote:
> > On Wed, 2016-09-28 at 11:43 -0400, Ken Hornstein wrote:
> >> >Storing: Simply on a ram filesystem and use ACLS to tackle it down to
> >> >the list of users who need it. This is pretty much what KEYRING does,
> >> >with a custom nonstandard api.
> >>
> >> FWIW, we are going to KEYRING everywhere; the semantics for what you
> >> want in terms of a credential cache store are almost perfect.  What you
> >> DON'T want to do is store credentials on a filesystem (be it in RAM or
> >> on spinning disk); been there, done that.  As for the leaking of information
> >> across chroot/Docker containers ... I'm trying to imagine how that would
> >> be an actual security problem in practice.  I could be proven wrong, of
> >> course, but I'd like to see some more concrete risks here.
> >
> > It becomes a potential security issue if you run containers as root, but
> > nobody is doing that in production, right ? Because if you do, the
> > keyring issue is not the major problem here.
> >
> > Besides there are various part of the kernel that depends on the keyring
> > now, disabling it is going to cause hard to diagnose issues or limit the
> > features you can use.
>
> That's hard to believe now that AWS and Google clouds have keyring
> support patched out of their kernels (SEL at least), too. Syscalls are
> still there but they all return not supported.

They probably do not need it in their main use cases. But in the VMs you
can run your own kernel so you can use what you like.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

abdullahrao
Hi,

I had faced the same issue and found that I had to change the value for
default_ccache_name from "KEYRING:persistent:%{uid}" to "/tmp/krb5cc_%{uid}"



--
Sent from: http://kerberos.996246.n3.nabble.com/Kerberos-General-f11810.html
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Charles Hedrick
we use a pam module that normalizes the credential cache. If krb5.conf asks for KEYRING and sshd leaves the cache in /tmp, the code moves it into KEYRING and updates KRB5CCNAME.

I really like KEYRING. Our staff have multiple principals. With a collection, kinit will create a new cache in the collection without disrupting the old one, so kswitch can take you back. We use two-factor, so we’d rather not have to get new credentials.

However there’s a gotcha. Kerberized NFS uses (by default) the currently selected principal. So for a collection to be useful, we also have a ccselect plugin to make sure that NFS (actually rpc.gssd) always gets the right principal from the collection.


> On Mar 5, 2020, at 11:44:47 PM, abdullahrao <[hidden email]> wrote:
>
> Hi,
>
> I had faced the same issue and found that I had to change the value for
> default_ccache_name from "KEYRING:persistent:%{uid}" to "/tmp/krb5cc_%{uid}"
>
>
>
> --
> Sent from: http://kerberos.996246.n3.nabble.com/Kerberos-General-f11810.html
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Ken Dreyer-2
On Tue, Apr 7, 2020 at 8:39 AM Charles Hedrick <[hidden email]> wrote:
>
> we use a pam module that normalizes the credential cache. If krb5.conf
> asks for KEYRING and sshd leaves the cache in /tmp, the code moves it
> into KEYRING and updates KRB5CCNAME.

Is this pam module open-source? It sounds like you've implemented what
Russ described earlier in this thread.

> However there’s a gotcha. Kerberized NFS uses (by default) the
> currently selected principal. So for a collection to be useful, we
> also have a ccselect plugin to make sure that NFS (actually rpc.gssd)
> always gets the right principal from the collection.

I'm interested in this as well, if it's open-source!

- Ken

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: KEYRING:persistent and ssh

Charles Hedrick
yes. https://github.com/clhedrick/kerberos  pam_reg_cc.

However this module does additional things, primarily registering cc’s for renewd to renew. If you’re not using renewd, you might want to remove the call to register_for_delete


> On Apr 13, 2020, at 1:13:21 AM, Ken Dreyer <[hidden email]> wrote:
>
> On Tue, Apr 7, 2020 at 8:39 AM Charles Hedrick <[hidden email]> wrote:
>>
>> we use a pam module that normalizes the credential cache. If krb5.conf
>> asks for KEYRING and sshd leaves the cache in /tmp, the code moves it
>> into KEYRING and updates KRB5CCNAME.
>
> Is this pam module open-source? It sounds like you've implemented what
> Russ described earlier in this thread.
>
>> However there’s a gotcha. Kerberized NFS uses (by default) the
>> currently selected principal. So for a collection to be useful, we
>> also have a ccselect plugin to make sure that NFS (actually rpc.gssd)
>> always gets the right principal from the collection.
>
> I'm interested in this as well, if it's open-source!
>
> - Ken


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos