Christian Salzmann <salzmann-st...@mi.fu-berlin.de> writes: > Apologies for not getting back to you sooner; > I had to spend a couple of days in hospital.
Ack! I hope you're feeling much better now. I'm fairly mystified by this problem, unfortunately. I have a similar UNIX and AD cross-realm setup here and configured a UNIX server to have its primary realm be the AD realm, and then logged in to an account using the password for an AD principal, and everything worked fine, including the principal verification. So unfortunately I can't reproduce the problem that you're having. The plus side is that means that I don't think anything fundamental is wrong. The trick is figuring out what's different about my configuration compared to your configuration. > I even find the correct service principal in my cred cache after a > failed login attempt: > $ ssh adtest > Password: > Password: > ^C > $ klist > Ticket cache: FILE:/tmp/krb5cc_11752_K19908 > Default principal: salzmann@<AD realm> > Valid starting Expires Service principal > 01/25/11 17:36:03 01/26/11 03:36:09 krbtgt/<AD realm>@<AD realm> > renew until 01/26/11 17:36:03 > 01/25/11 17:36:19 01/26/11 03:36:09 krbtgt/<UX realm>@<AD realm> > renew until 01/26/11 17:36:03 > 01/25/11 17:36:19 01/26/11 03:36:09 host/<principal>@<UX realm> > renew until 01/26/11 17:36:03 This is, unfortunately, a red herring. This is the ssh client attempting to log on via GSSAPI authentication, for which it obtains a service ticket for the ssh server. GSSAPI fails for some reason (do you expect it to work, or is it disabled on the server?), so the ssh client falls back to password. The part that's failing for you is the validation of the TGT obtained by the server with password authentication, and happens only on the server (in a temporary ticket cache in /tmp). Unfortunately, it leaves no artifacts on the client, so there's no way to tell from the client side where or why it's failing. If you would expect GSSAPI authentication to sshd to work, however, this may be a clue as to what might be wrong, since it's possible that GSSAPI authentication is failing due to the same host key mismatch that is causing the TGT verification to fail. The krb5.conf file looks fine. When I tested this, I omitted the capaths section since direct trust shouldn't require it, but that also shouldn't make any difference. In order to rule out ssh doing something weird, are you in a position to attempt a console login on this system with the same user and password that you're using for ssh? (It's possible to just run login as root and test console login that way if this is a server where you don't have easy access to the console.) If that works, maybe we can figure out how to trace the Kerberos library calls inside login to figure out what's failing, which will be easier than trying to do the same with sshd. Everything agrees about the FQDN of this system, right? (Local /etc/hosts, DNS forward lookup, DNS reverse lookup, etc.) Kerberos is notoriously sensitive to that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
