[38717] in Kerberos
Re: KEYRING:persistent and ssh
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Tue Apr 7 10:27:52 2020
From: Charles Hedrick <hedrick@rutgers.edu>
To: abdullahrao <abdullah.s.rao@gmail.com>
Date: Tue, 7 Apr 2020 14:24:52 +0000
Message-ID: <487A90D2-1E48-4052-845F-E6B7D6DBDA1A@cs.rutgers.edu>
In-Reply-To: <1583469887842-0.post@n3.nabble.com>
Content-Language: en-US
Content-ID: <3A8B5A70BB4CBF468805D57520321587@namprd14.prod.outlook.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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 <abdullah.s.rao@gmail.com> 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
