You sent:
...
> telnet> set authdebug
> auth debugging enabled
> telnet> open kplz354s2
> Trying 10.25.1.14...
> Will send login name and/or authentication information.
> Connected to kplz354s2.d.umn.edu (10.25.1.14).
> Escape character is '^]'.
> >>>TELNET: I support auth type 2 6
> >>>TELNET: I support auth type 2 2
> >>>TELNET: I support auth type 2 0
> >>>TELNET: auth_send got: 02 02 02 00
> >>>TELNET: He supports 2
> >>>TELNET: Trying 2 2
> telnet: calling krb5_sname_to_principal
> telnet: done calling
> krb5_sname_to_principal
>
> >>>IS:0: [0] (448) 6e 82 01 bc 30 82 01 b8 a0 03 02 01 05 a1 03 02
> telnet: Sent Kerberos V5 credentials to server
> >>>TELNET: Using type 2
> [ Kerberos V5 accepts you as ``[email protected]'' ]
>
> % Authentication failed
> Connection closed by foreign host.
...
I dusted off some old telnet binaries, which produce quite
similar output to what you report:
lancashire$ kinit
Password for [email protected]:
lancashire$ klist
Ticket cache: FILE:/tmp/krb5cc_25131
Default principal: [email protected]
Valid starting Expires Service principal
04/02/10 17:00:24 04/03/10 03:00:24
krbtgt/[email protected]
lancashire$ telnet -a
telnet> set authdebug
auth debugging enabled
telnet> open galois
Trying 141.213.229.76...
Connected to galois.ifs.umich.edu (141.213.229.76).
Escape character is '^]'.
>>>TELNET: I support auth type 2 6
>>>TELNET: I support auth type 2 2
>>>TELNET: I support auth type 2 0
>>>TELNET: auth_send got: 02 06 02 02 02 00
>>>TELNET: He supports 2
>>>TELNET: He supports 2
>>>TELNET: Trying 2 2
telnet: calling krb5_sname_to_principal
telnet: done calling krb5_sname_to_principal
>>>IS:0: [0] (509) 6e 82 01 f9 30 82 01 f5 a0 03 02 01 05 a1 03 02
telnet: Sent Kerberos V5 credentials to server
>>>TELNET: Using type 2
[ Kerberos V5 accepts you as ``[email protected]'' ]
Last login: Fri Apr 2 17:00:11 from lancashire
galois$
galois$ logout
Connection closed by foreign host.
lancashire$ klist -fea
Ticket cache: FILE:/tmp/krb5cc_25131
Default principal: [email protected]
Valid starting Expires Service principal
04/02/10 17:00:24 04/03/10 03:00:24
krbtgt/[email protected]
Flags: I, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1
HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
Addresses: (none)
04/02/10 17:00:39 04/03/10 03:00:24
host/[email protected]
Flags: T, Etype (skey, tkt): DES cbc mode with CRC-32, AES-256
CTS mode with 96-bit SHA-1 HMAC
Addresses: (none)
lancashire$
In my case, the server key happens to be AES - the rest is much
as you report.
Now that I've read slightly more of the telnet/telnetd code:
I believe the string 'Kerberos 5 accepts you as' can only appear when
the remote end indicates that it has accepted a kerberos ticket, so
I think that's probably ok. The string that appears after that
comes from the other end, and the name information almost certainly
comes from inside the ticket, which means it was able to decrypt
the ticket. So you really do nearly have this working.
The string 'Last login: Fri Apr 2 17:00:11 from lancashire' is
the first thing that is produced by the login program, and that's
where your output diverges.
You might want to try enabling encryption and decryption.
$ telnet -x -a
or
telnet> set autologin
telnet> set autoencrypt
telnet> set autodecrypt
telnet> set verbose_encrypt
telnet> open ...
Also perhaps
telnet> set encdebug
The unix version of telnetd supports an option to require encryption,
when this is enabled, the telnet connection ``hangs'' after connect
until the client enables encryption -- right at the point where your
cisco connection appears to fail. Perhaps the cisco telnetd isn't
as patient, or perhaps you have some other sort of authorization
problem at that point.
For the sake of comparision, here's what I get if I move the keytab
aside on lancashire:
lancashire$ telnet
telnet> set autologin
Will send login name and/or authentication information.
telnet> set authdebug
auth debugging enabled
telnet> open galois
Trying 141.213.229.76...
Connected to galois.ifs.umich.edu (141.213.229.76).
Escape character is '^]'.
>>>TELNET: I support auth type 2 6
>>>TELNET: I support auth type 2 2
>>>TELNET: I support auth type 2 0
>>>TELNET: auth_send got: 02 06 02 02 02 00
>>>TELNET: He supports 2
>>>TELNET: He supports 2
>>>TELNET: Trying 2 2
telnet: calling krb5_sname_to_principal
telnet: done calling krb5_sname_to_principal
>>>IS:0: [0] (509) 6e 82 01 f9 30 82 01 f5 a0 03 02 01 05 a1 03 02
telnet: Sent Kerberos V5 credentials to server
>>>TELNET: Using type 2
[ Kerberos V5 refuses authentication because telnetd: krb5_rd_req
failed: No such file or directory ]
>>>TELNET: He supports 2
>>>TELNET: Trying 2 0
telnet: calling krb5_sname_to_principal
telnet: done calling krb5_sname_to_principal
>>>IS:0: [0] (509) 6e 82 01 f9 30 82 01 f5 a0 03 02 01 05 a1 03 02
telnet: Sent Kerberos V5 credentials to server
>>>TELNET: Using type 2
[ Kerberos V5 refuses authentication because telnetd: krb5_rd_req
failed: No such file or directory ]
>>>TELNET: Sent failure message
telnetd: Authorization failed.
Connection closed by foreign host.
lancashire$
In this case, I see that the string "Kerberos V5 refuses authentication because
"
comes from the local telnet binary. The string "telnetd: krb5_rd_req failed:
No such file or directory" comes from telnetd on the other side.
> > If the string you rightfully didn't show us is really a srvtab, the
> > service principal you gave to the cisco must not have any non-des key
> > types in the kdc.
>
> Why do you say that? (ie. I'm not following this last statement)
Again, I think given that you are seeing 'Kerberos 5 accepts you as' that
whatever key information you have on your cisco is correct. So I don't
you need to figure out what you have for a "srvtab". However,
in case you're curious:
A srvtab is a kerberos 4 file which contains one or more service keys.
Because it's kerberos 4 specific, it can only hold DES keys, and
the name has some additional format restrictions.
Here's a sample keytab:
$ klist -kKe FILE:/home/mdw/aardvark.keytab
Keytab name: WRFILE:/home/mdw/aardvark.keytab
KVNO Principal
----
--------------------------------------------------------------------------
3 host/[email protected] (DES cbc mode with
CRC-32) (0xd067fbec20f83d7f)
3 host/[email protected] (AES-256 CTS mode with
96-bit SHA-1 HMAC)
(0x4044f793ce3222ff7b5828df33a7f6394a8c77ed2b466e256a0615d5b8783db9)
$
000000: 5 2 0 0 0 45 0 2 0 e 43 41 54 53 2e 55 .....E....CATS.U
000010: 4d 49 43 48 2e 45 44 55 0 4 68 6f 73 74 0 16 MICH.EDU..host..
000020: 61 61 72 64 76 61 72 6b 2e 69 66 73 2e 75 6d 69 aardvark.ifs.umi
000030: 63 68 2e 65 64 75 0 0 0 1 4b b6 62 7 3 0 ch.edu....K.b...
000040: 1 0 8 d0 67 fb ec 20 f8 3d 7f 0 0 0 5d 0 ....g.. .=....].
000050: 2 0 e 43 41 54 53 2e 55 4d 49 43 48 2e 45 44 ...CATS.UMICH.ED
000060: 55 0 4 68 6f 73 74 0 16 61 61 72 64 76 61 72 U..host..aardvar
000070: 6b 2e 69 66 73 2e 75 6d 69 63 68 2e 65 64 75 0 k.ifs.umich.edu.
000080: 0 0 1 4b b6 62 7 3 0 12 0 20 40 44 f7 93 ...K.b..... @D..
000090: ce 32 22 ff 7b 58 28 df 33 a7 f6 39 4a 8c 77 ed .2".{X(.3..9J.w.
0000a0: 2b 46 6e 25 6a 6 15 d5 b8 78 3d b9 +Fn%j....x=.
0000ac:
And a srvtab made from this:
$ klist -kKe SRVTAB:/home/mdw/aardvark.srvtab
Keytab name: SRVTAB:/home/mdw/aardvark.srvtab
KVNO Principal
----
--------------------------------------------------------------------------
3 host/[email protected] (DES cbc mode with
CRC-32) (0xd067fbec20f83d7f)
$
000000: 72 63 6d 64 0 61 61 72 64 76 61 72 6b 0 43 41 rcmd.aardvark.CA
000010: 54 53 2e 55 4d 49 43 48 2e 45 44 55 0 3 d0 67 TS.UMICH.EDU...g
000020: fb ec 20 f8 3d 7f .. .=.
000026:
The most important difference is the srvtab only has the DES key.
Besides this, notice that the srvtab does not start with ENQ, formats
the name differently, only uses one byte for the kvno, and lacks the
creation timestamp, encryption type, and key length.
...
-Marcus Watts
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
