"The Linux Gazette...making Linux just a little more fun!"

"telnetd connected:" But No "login" Prompt

From cbgyeh on Mon, 11 Oct 1999

Hi,

I appreciate that if you can help me the problem related to telnet running RedHat 6.0.

I recently configured RedHat 6.0. When I telnet to the server, I see the banner message. There is no login prompt. The /var/log/secure indicates telnetd connected from xxx.xxx.xxx.xxx. When I test the loop back i.e. 127.0.0.1, the telnetd works correctly. Ping and ftp work well. FTP has no delay at all.

I did not install any patches yet. Ching

It sounds like a TCP Wrappers problem.

Linux systems normally have TCP Wrappers (tcpd) preconfigured to provide selective access control to all 'inetd' launched services. You'll see this if you look in your /etc/inetd.conf. Thus 'inetd' is configured to listen to the telnet service port (23, as listed in /etc/services). 'inetd' find 'tcpd' and runs that. Thus 'inetd' won't complain about a "program not found."

TCP Wrappers will log the connection attempt (under the service name). Then it will do a double-reverse lookup (taking the source IP address of the connection, getting a purported host/domain name, then doing a a forward lookup of that to scan for the original source IP address). If those values are inconsistent it may just drop the connection or it may continue as normal.

TCP Wrapper will then check the /etc/hosts.allow and the /etc/hosts.deny files. It will look for a line that applies to this service (in.telnetd) followed by a list of allowed (or denied) IP address or host/domain name patterns. The syntax of these files is described in the hosts_access man pages.

I've described TCP Wrappers and this double reverse lookup before. If you're reverse DNS zones aren't properly configured you may seen very log delays on connections at this point (several minutes). You're test from localhost succeeds because you have localhost (127.0.0.1) listed in your /etc/hosts file so the forward and reverse records will always be correct so long as the 'files' entry in your /etc/nsswitch.conf (/etc/hosts.conf for older libc5 packages) is properly maintained.

Usually your FTP daemon would also be protected this way. However, new Linux distributions sometimes are using ProFTPd which is often run "standalone" (not through the inetd dispatcher). ProFTPd has optional service access controls of it's own (and might not be configured to do this "double-reverse lookup").

So, try adding the appropriate IP addresses and names to your /etc/hosts file or get your hostmaster to get your reverse zone maps configured properly. If that doesn't work trying using strace. To do that replace the in.telnetd line in your /etc/inetd.conf file with something like:

telnet         stream  tcp     nowait  telnetd.telnetd /usr/sbin/tcpd  /root/bin/trace.telnetd

... (all on one line, of course --- the backslash is just to note that this is a "continued" line in my e-mail --- DON'T put that in the inetd.conf file).

"/root/bin/trace.telnetd" is a shell script that looks like:

#!/bin/sh
exec strace -o root/tmp/telnetd.trace /usr/sbin/in.telnetd

... that can give you a system call trace of what the telnet daemon is doing after its launched. Of course you have to signal your inetd to re-read it's configuration file using a command like:

kill -HUP $(cat /var/run/inetd.pid)

... in order for this change to take effect. (It would also take effect after a reboot, of course).

NOTE: I don't recommend that you run with this strace script during normal production use. It could be insecure and it's likely to be a bad idea in any event. However, it's useful for capturing some low level diagnostic data.

Reading strace output is challenging. However, you can usually get by okay by simply looking for failed open(), stat(), and lstat() calls.

If that line doesn't work (you don't get any telnet.trace output) try:

telnet         stream  tcp     nowait  telnetd.telnetd         /root/bin/trace.telnetd         telnetd

... (all on one line, as before). In this case we are eliminating tcpd from the picture. The confusing part about the inetd.conf file syntax is that you seem to repeat the name of the program your running twice on each service line. The first reference is the program that will be run, the next is the name under which it will appear in a 'ps' (process status) listing and anything else on the line will be passed as command line arguments to the daemon.

This ability to separately supply an executable patch/name and a full argument list, including "arg(0)" --- the 'ps' name --- is normal for UNIX and Linux, it's just not something you'd see from using the command shell. That and 'init' always start programs using the same value for both the executable path and the arg(0).

I doubt you'll have to go to that level of debugging for this. I'm just describing the technique (again) for other readers and in case you do need it.

Ying at New York: Re: RedHat 6.0:Telnet has no login prompt

From chgyeh on Fri, 15 Oct 1999

Jim,

Thank you so much for showing me strace command. I was able to look at the trace file and determined my nsswitch was not correct. It was hanging at the nis+ which I did not configure to use. Again, thank you for your help.

Ching

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57