Some (better, I'd say) telnet implementations don't initiate any telnet option processing if you specify a (non-standard) port# so you *can* use it to test other tcp-based protocols. Looks like this was doesn't (but perhaps it has an option to do so).
John > On Jul 6, 2004, at 11:24, Carretti Enrico wrote: > > > Hi all, I'd like to submit you a problem: I've configured kerberos > > properly on > > a machine; I've done all the necessary configuration and I can locally > > perform > > "kerberized" telnet sessions, in fact I've replaced the UNIX daemon > > with the > > kerberized one. On the same machine I've also installed Apache, > > becouse in my > > plan I have to let Apache and Kerberos "talk" (with mod_auth_kerb). The > > configuration of the web server is fine, in fact I point my browser on > > the > > port 80 and I can see the default page of Apache. See that Apache and > > Kerberos > > are NOT YET in communication! The problem comes now: I want to test the > > correct installation of Apache simulating an HTTP session with telnet > > (using > > the kerberized version of client and server, of course) and I perform: > > I think you're a bit confused about how Kerberos authentication is > performed. It's not a single specific exchange stuck on the front of > every application protocol. In the Telnet protocol, there's an > exchange built in to say "I want to do authentication", "these are the > methods I support", "here's the data". The HTTP protocol has hooks for > authentication too, and a way of using Kerberos within that framework, > but they aren't the same as for telnet. > > > > $ telnet -a <my.machine> 80 > > GET / HTTP/1.1 > > Host: <my.machine> > > > > but Apache returns an error, the 501 (i.e. Method not implemented). > > This is > > quite strange but comes clearer if I look to error.log, where I have > > > > [...] "\xff\xfb%GET / HTTP/1.0" 501 304 > > > > This means that before GET there are some other characters ( \xff\xfb% > > ), as > > you see not written by me, that make the request fail. Trying with a > > non > > kerberized client to preform the same process I get a correct answer > > by the > > server. > > That's the telnet protocol sequence "IAC WILL AUTHENTICATE". If it got > a proper telnet-protocol response saying the server supported it, it > might follow up with the Kerberos credentials. But the web server > expects a different means to be used to incorporate the authentication > data from the client. > > Look at the RFCs for the two protocols and you'll see each specifies > how to do authentication. > > > Now the final question: those strange characters before GET are > > something like > > the end of the stream of the negotiation with the kerberized telnet > > server put > > there for error?? > > Close. It's the telnet-protocol offer to do authentication. Since the > server doesn't answer that offer, the authentication isn't actually > done. > > As far as I know, you can't use telnet to test the Kerberos support in > Apache. (Well, not by itself. If you wrote a helper application to > get the tickets and format the authentication header to send to the > server, you could cut and paste it into the telnet session.) > > Ken > > ________________________________________________ > Kerberos mailing list [EMAIL PROTECTED] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
