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
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
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
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
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
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
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
>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
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)
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
> 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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo