Mats Erik Andersson <[email protected]> writes: > As you stated yourself on [email protected], and as I could > verify, an MIT client is not able to contact your TELNET server > at "interop.josefsson.org". The authentication works correctly, > but the actual payload exchange fails, which I interpreted as > being due to encryption. Am I mistaken?
Ah. That problem is different, but I agree it needs analysis. However, it is authentication that fails. If I use MIT/Heimdal telnet, I get errors like this: jas@latte:~$ telnet.krb5 -l user interop.josefsson.org Trying 178.79.173.181... Automatic decryption of input is enabled Automatic encryption of output is enabled Will send login name and/or authentication information. auth debugging enabled Encryption is verbose Connected to interop.josefsson.org (178.79.173.181). 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 telnet: Kerberos V5: failure on credentials(No credentials found with supported encryption types) I suspect the problem is that MIT/Heimdal is somehow expecting/requiring that DES keys are available, which I haven't added. I don't understand why MIT/Heimdal doesn't use AES for everything except a DES sub-session key. I'll see if adding DES keys for the krbtgt and/or host and/or user will help. Anyway, while we should make sure this works, I suspect it is more a of MIT/Heimdal issue. /Simon
