MIT + Heimdal + openssh == cross realm difficulties

[Priit Randla]

Douglas E. Engert wrote:

> do you have a .k5login file in the home directory on srv1.bbb
> which has
> priitr at AAA
>
>
    Well, of cource I didn't. When I created it, I could log in using 
both telnet and openssh. Thank You,
I haven't used .rlogin-alikes a long time now...
But certainly there is another way to do that; I mean, as I have lots of 
workstations and
servers (~ 1000) to log on, there should be another way to maintain 
cross-realm trust, shouldn't it?
To create .k5login files for every account on every host doesn't seem 
like an elegant solution?
Hopefully I'm overlooking something trivial, could you please enlighten 
me? I really don't know...

Priit

> Priit Randla wrote:
>
>> Jeffrey Hutzelman wrote:
>>
>>>> "Client not found in database: priitr at AAA: No such entry in the 
>>>> database"
>>>>
>>>> Ask the Heimdal people, what does this message mean? 
>>>
>>>
>>>
>>    Well, I haven't got any answers from Heimdal list so far.
>>
>>>> With cross realm,
>>>> the server's realm should not require any knowlwdge of the user 
>>>> principal
>>>> and should not require it to be in its database.
>>>
>>>
>>>
>>>
>>> It means what it said - the client is not in that KDC's database.
>>> It does not mean that the KDC is refusing to issue a ticket.
>>
>>
>>
>>
>>    It's getting stranger (for me).  I dumped Heimdal for now and 
>> tried to get at least some form
>> of cross-realm trust going betveen  two MIT kdc's. No such luck.
>> I created same principals as in Heimdal case, tried ssh again:
>>
>> ssh -vvvvvvvvvvv srv1.bbb
>> debug2: Next authentication method: gssapi-with-mic
>> debug2: we sent a gssapi-with-mic packet, wait for reply
>> debug1: Delegating credentials
>> debug1: Delegating credentials
>> debug1: Authentications that can continue: 
>> publickey,gssapi-with-mic,gssapi,keyboard-interactive
>> debug2: we sent a gssapi-with-mic packet, wait for reply
>> debug1: Authentications that can continue: 
>> publickey,gssapi-with-mic,gssapi,keyboard-interactive
>> debug2: we did not send a packet, disable method
>> debug3: authmethod_lookup publickey
>> debug3: remaining preferred: keyboard-interactiva,password
>>
>> klist:
>> Ticket cache: FILE:/tmp/krb5cc_500
>> Default principal: priitr at AAA
>> Valid starting     Expires            Service principal
>> 02/04/05 18:03:21  02/05/05 08:03:21  krbtgt/AAA at AAA
>>        renew until 02/04/05 18:03:21
>> 02/04/05 18:05:06  02/05/05 08:03:21  krbtgt/BBB at AAA
>>        renew until 02/04/05 18:03:21
>> 02/04/05 18:05:06  02/05/05 08:03:21  host/srv1.infra3.ad4.seb.net at BBB
>>        renew until 02/04/05 18:03:21d-interactive,password
>>
>> On server side: sshd log
>>                                                   debug3: 
>> mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 3
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_answer_authserv: 
>> service=ssh-connection, style=
>> Feb  4 18:09:04 linux sshd[17922]: debug2: monitor_read: 3 used once, 
>> disabling now
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 37
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_send entering: 
>> type 38
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 39
>> Feb  4 18:09:04 linux sshd[17922]: debug1: Received some client 
>> credentials
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_send entering: 
>> type 40
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 43
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_send entering: 
>> type 44
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 41
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_answer_gss_userok: 
>> sending result 0
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_send entering: 
>> type 42
>> Feb  4 18:09:04 linux sshd[17922]: Failed gssapi-with-mic for priitr 
>> from ::ffff:172.26.209.15 port 44702 ssh2
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: monitor_read: checking 
>> request 48
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_answer_pam_init_ctx
>> Feb  4 18:09:04 linux sshd[17922]: debug3: PAM: sshpam_init_ctx entering
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_send entering: 
>> type 49
>> Feb  4 18:09:04 linux sshd[17922]: debug3: mm_request_receive entering
>>
>> I also tried to test with kerberized telnet, still no luck:
>> client side:
>> telnet -F -a  -d srv1.bbb
>> Trying 172.26.209.10...
>> Connected to srv1.bbb (172.26.209.10).
>> Escape character is '^]'.
>> [ Kerberos V5 accepts you as ``priitr at AAA'' ]
>> [ Kerberos V5 accepted forwarded credentials ]
>> Password for priitr:
>>
>> server side:
>>  >>>TELNETD: I support auth type 2 6
>>  >>>TELNETD: I support auth type 2 2
>>  >>>TELNETD: I support auth type 2 0
>>  >>>TELNETD: I will support DES_CFB64
>>  >>>TELNETD: I will support DES_OFB64
>>  >>>TELNETD: Sending type 2 6
>>  >>>TELNETD: Sending type 2 2
>>  >>>TELNETD: Sending type 2 0
>>  >>>TELNETD: in auth_wait.
>>  >>>TELNETD: Got NAME [priitr]
>>  >>>REPLY:2: [3] (91) 6f 59 30 57 a0 03 02 01 05 a1 03 02 01 0f a2 4b
>>  >>>REPLY:2: [2] (13) 70 72 69 69 74 72 40 45 59 50 2e 45 45
>> telnetd: Kerberos5 identifies him as ``priitr at AAA''
>>  >>>TELNETD: He is supporting DES_CFB64 (1)
>>  >>>TELNETD: He is supporting DES_OFB64 (2)
>> Creating new feed
>>  >>>TELNETD: (*ep->start)() returned 6
>> CFB64: initial vector received
>> Initializing Decrypt stream
>> (*ep->is)(8060fc3, 9) returned MORE_TO_DO (7)
>>  >>>REPLY:2: [5] (0)
>> telnetd: Forwarded credentials obtained
>> (*ep->reply)(8060fc3, 1) returned MORE_TO_DO (4)
>>  >>>TELNETD: encrypt_reply returned 4
>>  >>>TELNETD: in encrypt_wait
>>
>> Priit
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>>
>