Can anybody tell me what this message means, and how to fix the
problem it appears to indicate?
May 13 17:46:52 goliath sshd[6468]: (pam_krb5): root: unable to get
PAM_KRB5CCNAME, assuming non-Kerberos login
Thanks.
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
For the record, this turned out to be the result of the user having a
bogus ~/.k5login.
- a
Russ Allbery <[EMAIL PROTECTED]> writes:
> Adam Megacz <[EMAIL PROTECTED]> writes:
>
>> Can anybody tell me what this message means, and how to fix the problem
>> it appe
I know the idea will make some people recoil in horror, but are there
any KDCs or patches out there that do this?
The idea would be that the KDC would issue a TGT to any user who could
prove they had posession of the private key corresponding to one of
the user's ~/.ssh/authorized_keys (assume fo
"Christopher D. Clausen" <[EMAIL PROTECTED]> writes:
> How exactly is having a private key password different from simply
> telling the user to kinit ONCE on their local machine before attempting
> to SSH to your Kerberized machines?
Because you have to kinit once **per realm**.
Most users als
>> Because you have to kinit once **per realm**.
> Well, if the passwords are differnet you can't get around that.
As they should be, because I do not want to entrust the admins of any
of the systems I use with knowledge of the password for my account on
other systems.
> And wouldn't a user nee
Thanks for taking the time to reply, Russ.
Russ Allbery <[EMAIL PROTECTED]> writes:
> PKINIT already exists and is already standardized,
Hrm, last I checked there was no RFC, just an internet-draft.
> so using X.509 certificates is much easier than using ssh private
> keys.
Perhaps for adminis
Ken Hornstein <[EMAIL PROTECTED]> writes:
> I may be an extreme case, but I have 20 cross-realm keys.
How many of those keys belong to administratively independent
organizations (ie if your home realm is part of .mil, how many of
those keys are for civilian organizations?) I'll readily concede t
John Hascall <[EMAIL PROTECTED]> writes:
> How many of the top-10 use Kerberos?
> And what exactly is the top-10 (which list?)(
> For the sale of argument lets say they are:
Well, based on AFS usage (which requires Kerberos right now), all of
the schools on your list except UT Austin must have a
"Christopher D. Clausen" <[EMAIL PROTECTED]> writes:
> UIUC has AFS? Is there some other UIUC that I don't know about?
Hrm, I was going by the fact that ncsa.uiuc.edu and acm.uiuc.edu are
both in the CellServDB that comes with OpenAFS (and appear to work),
but I guess those might be sub-campus-l
Jeffrey Altman <[EMAIL PROTECTED]> writes:
>> Hrm, last I checked there was no RFC, just an internet-draft.
> RFC 4456
> http://www.ietf.org/rfc/rfc4556.txt
Wow, sweet. What is the implementation status in current KDC's (MIT
and Heimdal)?
Currently my thinking is to patch pam_krb5 and add a fla
I've noticed that with most browsers the user needs to manually
configure their browser to tell it to delegate credentials to certain
hosts:
http://www.grolmsnet.de/kerbtut/credentialsdelegation.html
If the user does not do so, they tend to get a fairly unhelpful
message back from the server (
Ken Raeburn <[EMAIL PROTECTED]> writes:
>> I believe the future has already arrived. Current MIT code should
>> be capable of finding and using records like this:
>>
>> spam% dig _kerberos-adm._tcp.umich.edu srv
>
> This is used for the password-changing service, but unfortunately the
> RP
Hi, would it be possible for the Kerberos maintainers to consider the
patch below for inclusion in the main libkadm5 distribution?
- a
Adam Megacz <[EMAIL PROTECTED]> writes:
> Ken Raeburn <[EMAIL PROTECTED]> writes:
>>> I believe the future has already arrived.
Tom Yu writes:
> The MIT Kerberos Team announces the availability of MIT Kerberos 5
> Release 1.7.
Hi, Tom. Congratulations on the release!
I noticed that this patch (or equivalent functionality) was not
included:
http://www.mail-archive.com/kerberos@mit.edu/msg13929.html
Are there any pla
eburn writes:
> Sure. :)
> At first glance it looks good, but I want to have a closer look
> before committing it (unless someone else gets to it first). Thanks
> for sending it in!
>
> Adam Megacz writes:
> > Hi, would it be possible for the Kerberos maintainers to con
I find that OpenSSH (5.1p1 on both sides) will silently refuse to
delegate credentials if the principal being delegated lacks the
REQUIRES_PRE_AUTH attribute. Adding that attribute at the KDC and
re-issuing the principal's tickets causes everything to work perfectly.
Is this behavior intentional
Related to my previous posting, I find that even though I have
default_principal_flags = +preauth
in kdc.conf, when I use kadmin.local's "ank -randkey" command to create
a service principal, the principal is created with no attributes.
Principals created with "addprinc" and a password provided
Russ Allbery writes:
> Check the host/* principal on the system to which you were authenticating.
> I bet that the REQUIRES_PRE_AUTH flag was set for it, which means that
> only tickets that are pre-authenticated can authenticate to that service
> principal.
Indeed, that was it! Russ saves the
Russ Allbery writes:
> I haven't looked at the code personally, but what I recall from what other
> people have said is that the code is structured so that doing proper error
> reporting is fairly difficult.
I can see how it might be difficult to get a message back to the client,
but it can't be
19 matches
Mail list logo
