Sam Hartman hartm...@debian.org writes:
Hi. At today's release meeting, MIT indicated that they are going to
set up an OSX X test environment to reproduce this problem. They will
also look into whether we can ignore the PAC and remove it from the
authdata if it fails to verify rather than
This patch looks reasonable. I have not confirmed that successfully
makes the PAC disappear, but if you've examined the logic there I'm
happy to assume it does.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Sam Hartman hartm...@debian.org writes:
This patch looks reasonable. I have not confirmed that successfully
makes the PAC disappear, but if you've examined the logic there I'm
happy to assume it does.
On the other hand, we do appear to expose the krb5_pac_verify()
interface that is called by
forwarded 604925
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6839user=guestpass=guest
tags 604925 + confirmed upstream fixed-upstream
thanks
I committed a slightly different fix that avoids breaking the
krb5_pac_verify() API.
http://src.mit.edu/fisheye/changelog/krb5/?cs=24564
--
To
Hi Sam,
On Tue, Nov 30, 2010 at 10:25:57AM -0500, Sam Hartman wrote:
The 1.9 packages just made their way into experimental.
I'd expect that
I'd expect
aptitude -t experimental install libkrb5-3 libgssapi-krb5-2
would work and not bring any scary dependencies in. If it does look
scary,
Can you try turning off delegated credentials? GSSAPIDelegateCreds no
in your client config? This is a shot in the dark, but I don't think
I've ever seen a problem with the authenticator path once the ticket is
decrypted. There is a first for everything, but the delegation path is
more fragile.
Thanks for still bearing with me!
On Tue, Dec 07, 2010 at 10:14:08AM -0500, Sam Hartman wrote:
Can you try turning off delegated credentials? GSSAPIDelegateCreds no
in your client config? This is a shot in the dark, but I don't think
I've ever seen a problem with the authenticator path once
There's a #kerberos?
Who knew!
So, I'd like to confirm.
You have a Mac OS Open Directory KDC and a lenny client.
When you authenticate to a squeeze server you get authdata verification
failure?
Have you failed to try authentication from squeeze to squeeze or does
that also fail?
--
To
On Tue, Dec 07, 2010 at 11:39:14AM -0500, Sam Hartman wrote:
There's a #kerberos?
Who knew!
On Freenode. :-)
So, I'd like to confirm.
You have a Mac OS Open Directory KDC and a lenny client.
When you authenticate to a squeeze server you get authdata verification
failure?
Correct. What
Hi. At today's release meeting, MIT indicated that they are going to
set up an OSX X test environment to reproduce this problem. They will
also look into whether we can ignore the PAC and remove it from the
authdata if it fails to verify rather than failing the authentication.
There was
Hi Sam,
thanks for bearing with us!
On Thu, Nov 25, 2010 at 02:01:02PM -0500, Sam Hartman wrote:
OK. The way in which the principal is determined changed between krb5
1.8 and 1.6. In 1.8 the system searches through all the keys in the
keytab looking for a key that successfully decrypts a
The 1.9 packages just made their way into experimental.
I'd expect that
I'd expect
aptitude -t experimental install libkrb5-3 libgssapi-krb5-2
would work and not bring any scary dependencies in. If it does look
scary, rebuild the experimental packages for squeeze.
Then you need to set
Package: libgssapi-krb5-2
Version: 1.8.3+dfsg-2
Severity: grave
File: /usr/lib/libgssapi_krb5.so.2
My system uses kerberos to authenticate users to ssh. After upgrading a server
to squeeze logging in is no longer possible (this could satisfy critical
severity). Unfortunately debugging this turned
tags 604925 moreinfo
severity 604925 normal
thanks
I'm guessing the no such file or directory is probably spurious. What's
probably happening is that something in libkrb5 or libgssapi_krb5 is
returning -1 in a context where the library belives it is a system call
that sets errno. However that's
Is your server keyed with a DES key?
Which server are you talking about? The kdc or the ssh server?
Maybe you can find the answer in the details below:
This is what my ticket (on the lenny client) looks like:
$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1000_FQS33c
Default principal:
OK.
I have no idea what's going on here.
If I were approaching this I'd step through things in the client and
server until I found the problem. So, I'm kind of shooting in the dark
here. Kerberos 1.9 includes a tracing facility that could help with
issues like this, but Kerberos 1.9 is not even
On Thu, Nov 25, 2010 at 11:55:16AM -0500, Sam Hartman wrote:
Is the default realm on your ssh server set to the realm in which it has
its host keys?
Yes.
Do things change if you add a domain_realm entry to your ssh server
mapping it into the realm where its key exists?
Good catch! Yes. The
OK. The way in which the principal is determined changed between krb5
1.8 and 1.6. In 1.8 the system searches through all the keys in the
keytab looking for a key that successfully decrypts a ticket. The
server name sent in the ticket over the network is ignored (at least by
sshd) and only the
18 matches
Mail list logo
