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  wrote:
> 
> On Tue, Apr 7, 2020 at 8:39 AM Charles Hedrick  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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Ken Dreyer]

On Tue, Apr 7, 2020 at 8:39 AM Charles Hedrick  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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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  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   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Simo Sorce]

On Wed, 2016-09-28 at 22:17 +0200, Cedric Blancher wrote:
> On 28 September 2016 at 19:01, Simo Sorce  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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Cedric Blancher]

On 28 September 2016 at 19:01, Simo Sorce  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 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Simo Sorce]

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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Lionel Cons]

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) 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  wrote:
>> On 27 Sep 2016, at 15:20, Tina Harriott  wrote:
>>
>>> On 16 September 2016 at 16:02, 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}_XX" cause ssh sets the KRB5CCNAME
>>> to file:/tmp/krb5cc_${uid}_XX...
>>> 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   Kerberos@mit.edu
>>> 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 al)
>> unrelated users/uids can obtain the secure data.
>>
>> Tina
>> --
>> Tina Harriott  - Women in Mathematics
>> Contact: tina.harriott.m...@gmail.com
>
> 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   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos



-- 
Lionel

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Simo Sorce]

On Tue, 2016-09-27 at 15:20 +0200, Tina Harriott wrote:
> On 16 September 2016 at 16:02, 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}_XX" cause ssh sets the KRB5CCNAME
> > to file:/tmp/krb5cc_${uid}_XX...
> > 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   Kerberos@mit.edu
> > 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 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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[t Seeger]

> On 27 Sep 2016, at 15:20, Tina Harriott  wrote:
> 
>> On 16 September 2016 at 16:02, 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}_XX" cause ssh sets the KRB5CCNAME
>> to file:/tmp/krb5cc_${uid}_XX...
>> 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   Kerberos@mit.edu
>> 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 al)
> unrelated users/uids can obtain the secure data.
> 
> Tina
> -- 
> Tina Harriott  - Women in Mathematics
> Contact: tina.harriott.m...@gmail.com

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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Roland C. Dowdeswell]

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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Tina Harriott]

On 16 September 2016 at 16:02, 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}_XX" cause ssh sets the KRB5CCNAME
> to file:/tmp/krb5cc_${uid}_XX...
> 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   Kerberos@mit.edu
> 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 al)
unrelated users/uids can obtain the secure data.

Tina
-- 
Tina Harriott  - Women in Mathematics
Contact: tina.harriott.m...@gmail.com

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[tseegerkrb]

On 21.09.2016 20:03, Russ Allbery wrote:
> tseegerkrb  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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Remove KEYRING from kernel! Re: KEYRING:persistent and ssh

[Cedric Blancher]

Depends what you call "nice". KEYRING is a gaping security hole in
case of Docker or chrooted apps because it "leaks" keys through the
isolation AND does this randomly even into other Docker instances.

IMO the whole KEYRING stuff should be removed from the Linux kernel
and replaced with a sane design.

Ced

On 21 September 2016 at 20:03, Russ Allbery  wrote:
> tseegerkrb  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 (ea...@eyrie.org)  
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos



-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Russ Allbery]

tseegerkrb  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 (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[tseegerkrb]

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  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, >krb5_fwd_ccache);
> # else
>  problem = krb5_cc_gen_new(authctxt->krb5_ctx, _fcc_ops,
>  >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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Russ Allbery]

tseegerkrb  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, >krb5_fwd_ccache);
# else
problem = krb5_cc_gen_new(authctxt->krb5_ctx, _fcc_ops,
>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 (ea...@eyrie.org)  

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[tseegerkrb]

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}_XX" cause ssh sets the KRB5CCNAME
>> to file:/tmp/krb5cc_${uid}_XX...
>> 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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: KEYRING:persistent and ssh

[Benjamin Kaduk]

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}_XX" cause ssh sets the KRB5CCNAME
> to file:/tmp/krb5cc_${uid}_XX...
> 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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

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}_XX" cause ssh sets the KRB5CCNAME
to file:/tmp/krb5cc_${uid}_XX...
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   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos