Douglas E. Engert wrote:
Well, of cource I didn't. When I created it, I could log in using both telnet and openssh. Thank You,do you have a .k5login file in the home directory on srv1.bbb which has [EMAIL PROTECTED]
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: [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] Valid starting Expires Service principal 02/04/05 18:03:21 02/05/05 08:03:21 krbtgt/[EMAIL PROTECTED] renew until 02/04/05 18:03:21 02/04/05 18:05:06 02/05/05 08:03:21 krbtgt/[EMAIL PROTECTED] renew until 02/04/05 18:03:21 02/04/05 18:05:06 02/05/05 08:03:21 host/[EMAIL PROTECTED] 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 [EMAIL PROTECTED]'' ] [ 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 [EMAIL PROTECTED]'' >>>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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
