Christian Salzmann <salzmann-st...@mi.fu-berlin.de> writes:
> Am 08.02.2011 02:02, schrieb Russ Allbery:
>> 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.
> Well, yes and no ;-)
> I ran the ssh command against the fqdn of the local machine. So in the
> shell context, the host is in fact capable of obtaining a TGT.
Is GSSAPI authentication enabled in /etc/ssh/sshd_config?
GSSAPIAuthentication yes
The reason why I'd pursue this angle is that if you have GSSAPI
authentication enabled, running sshd with -d -d will tell you immediately
what's failing about the GSSAPI authentication, which might provide us
with a valuable clue. (You can run an sshd on a separate port for testing
to not interrupt regular ssh service.)
>> 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.)
> Bad luck: same results for console login ...
Well, it's partly good luck in that it means that ssh isn't just doing
something weird. That also means that you can potentially run login under
strace (be careful, since that will include the password in the trace) and
try to figure out what exactly it's trying to do when it fails.
The GSSAPI approach will be easier, though.
Have you already tried adding:
verify_ap_req_nofail = false
to the [libdefaults] section of /etc/krb5.conf? I don't think the error
you're having is one that this will bypass, but it might be worth a shot.
> PS: The AD admin refused to establish a mutual trust, so it's only us
> trusting him. But I don't believe this is relevant.
I'm starting to wonder if this is it -- if, for some reason, it has to be
bidirectional in order to get the verification to work properly. Although
I'm not sure why that would be....
--
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
