MIT + Heimdal + openssh == cross realm difficulties
Douglas E. Engert
deengert at anl.gov
Mon Feb 7 11:36:50 EST 2005
Priit Randla wrote:
> 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?
Yes and no. The .k5login is really authorization, it is the ACL for
access to the user account on the host. By default it is assumed that
users in the same realm as the server, have matching local account names
and principal names, and thus no .k5login is needed.
If you want some default other then this you have to consider
the policies used with the two realms, i.e. a user in one is equivalent
to a user in the other, etc.
> 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...
With MIT see the auth_to_local rule in the krb5.conf:
http://web.mit.edu/kerberos/krb5-1.4/krb5-1.4/doc/krb5-admin.html#krb5.conf
Its something like this, better test it:
[realms]
ONE.EYP.EE = {
...
auth_to_local = RULE:[1:$1@$0](^.*@TWO.EYP.EE$)s/@TWO.EYP.EE//
auth_to_local = DEFAULT
}
TWO.EYP.EE = {
...
}
This would say that the host in realm ONE.EYP.EE would accept a
principal from realm TWO.EYP.EE as long as the user part of the principal
matched the local account.
Not sure if Heimdal has any thing similiar.
>
> 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
>>>
>>>
>>>
>>
>
>
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list