Wrong principal in request

[Jeff Blaine]

On 1/4/2010 8:42 PM, Russ Allbery wrote:
> Jeff Blaine<jblaine at kickflop.net>  writes:
>
>> I happened to notice this (note the missing realm) after a
>> failed GSSAPI attempt to the SSH server (mega):
>
>> [root at mega ~]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: jblaine at FOO
>
>> Valid starting     Expires            Service principal
>> 01/04/10 16:14:51  01/11/10 16:14:51  krbtgt/FOO at FOO
>>           renew until 01/18/10 16:14:51
>> 01/04/10 16:15:08  01/11/10 16:14:51  host/mega@
>>           renew until 01/18/10 16:14:51
>
> Ah, that means that the client doesn't know what the local realm is and is
> therefore trying to ask the server via referrals, but the server isn't
> answering that question.
>
>> I updated /etc/krb5.conf to include
>
>>       [domain_realm]
>>           mega = FOO
>
>> And all is well when connecting from mega to mega with OpenSSH
>> and GSSAPI options.
>
>> All is well, too, when connecting from sol10 SPARC stock SSH
>> to mega using GSSAPI options.
>
>> PuTTY-GSSAPI as the client still gives me the same error :(
>
> Did you update the Windows equivalent (krb5.ini, I think)?

I hadn't, but duplicated krb5.conf to C:\WINDOWS\krb5.ini to
replace the old one there (which worked fine for getting into
the Solaris 10 box via PuTTY + GSSAPI).

Same old same old.


OpenSSH sshd on mega reports:
...
mega sshd[3287]: debug1: userauth-request for user jblaine service 
ssh-connection method gssapi-with-mic
mega sshd[3287]: debug1: attempt 1 failures 1
mega sshd[3286]: debug1: PAM: setting PAM_RHOST to "192.168.1.4"
mega sshd[3286]: debug1: PAM: setting PAM_TTY to "ssh"
mega sshd[3287]: Postponed gssapi-with-mic for jblaine from 192.168.1.4 
port 50081 ssh2
mega sshd[3286]: debug1: Unspecified GSS failure.  Minor code may 
provide more information\nWrong principal in request\n
mega sshd[3286]: debug1: Got no client credentials
...

And the KDC reports:
...
AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.4: ISSUE: authtime 
1262662114, etypes {rep=18 tkt=18 ses=18}, jblaine at FOO for krbtgt/FOO at FOO
TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.4: ISSUE: authtime 
1262662114, etypes {rep=18 tkt=18 ses=18}, jblaine at FOO for 
host/192.168.1.6 at FOO
TGS_REQ (1 etypes {18}) 192.168.1.4: ISSUE: authtime 1262662114, etypes 
{rep=18 tkt=18 ses=18}, jblaine at FOO for krbtgt/FOO at FOO

After the failed GSSAPI attempt, KfW looks like the attached
image.