MIT + Heimdal + openssh == cross realm difficulties

[Priit Randla]

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