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

[Benjamin Kaduk]

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

[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

[Russ Allbery]

tseegerkrb <tseeg...@gmail.com> 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 (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>

[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.

[Russ Allbery]

tseegerkrb <tseeg...@gmail.com> 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.

[tseegerkrb]

On 21.09.2016 20:03, Russ Allbery wrote:
> tseegerkrb <tseeg...@gmail.com> 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?

[Tina Harriott]

On 16 September 2016 at 16:02, t Seeger <tseeg...@gmail.com> 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 Kerb...@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&et al)
unrelated users/uids can obtain the secure data.

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

[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/

[t Seeger]

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

[Simo Sorce]

On Tue, 2016-09-27 at 15:20 +0200, Tina Harriott wrote:
> On 16 September 2016 at 16:02, t Seeger <tseeg...@gmail.com> 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 Kerb...@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&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

[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&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 <tseeg...@gmail.com> wrote:

>> On 27 Sep 2016, at 15:20, Tina Harriott <tina.harr...@gmail.com> wrote:
>>
>>> On 16 September 2016 at 16:02, t Seeger <tseeg...@gmail.com> 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 Kerb...@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&et al)
>> unrelated users/uids can obtain the secure data.
>>

>> Tina
>> --
>> Tina Harriott - Women in Mathematics
>> Contact: tina.harr...@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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

--
Lionel

[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

[Simo Sorce]

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.

[Cedric Blancher]

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 <cedric....@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

[Simo Sorce]

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.

[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

[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.

[Ken Dreyer]

On Tue, Apr 7, 2020 at 8:39 AM Charles Hedrick <hed...@rutgers.edu> 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

[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