LINK="#3366FF" VLINK="#A000A0">


[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]


(?) The Answer Guy (!)


By James T. Dennis, tag@lists.linuxgazette.net
LinuxCare, http://www.linuxcare.com/


(?) Can't telnet to Linux server

From kd on Mon, 01 May 2000

I recently installed Suse Linux on a machine to be a server, but I cannot telnet to the linux server from my other machines. can you help?

~kelly

(!) Short answer: Probably TCP Wrappers and the old "double reverse lookup problem." Try adding an entry in /etc/hosts to refer back to your client(s) and make sure that your /etc/nsswitch.conf and /etc/hosts.conf are configured to honor "files" over DNS and NIS.
You could have been a bit more vague. You could have left out the word "telnet" ;)?
When asking people technical support questions you have to ask:
How many possible causes are there to this problem? How many of them have I eliminated? How have I eliminated them? Can I eliminate some more? What is the error message I'm getting (if any)? What was I expecting? What happened that didn't match that/those expection(s)?
For example: Can you ping the server from the client system? (That eliminates many IP addressing, routing, firewall and packet filtering questions). Can you telnet from that client to any other server? (That eliminates most of the questions that relate to proper client software/system configuration and function). Can I access any other service on this client? (Web server, file or print services, etc.)
Then you ask: What did I expect to happen when I telnetted to that system? I'd expect to get a set of responses something like:
Trying 123.45.67.89 Connected to myserver.mydomain.not Escape character is '^]'. Debian GNU/Linux 2.2 myserver.mydomain.not myserver login:
So, what did you get. Did you see the "Trying" line? That would mean that the telnet DNS or other hostname lookup returned something. Did the IP address in the trying line match that of your new server? That would mean that your DNS is correct! Did you get the "connected to" line? That suggests that the routing is correct. Did it just sit there for a long time? How long? What if you wait for five or ten minutes? Does it eventually connect?
It sounds like you have the old "double reverse DNS" problem. You are probably using DNS and you probably don't have proper reverse DNS (PTR) records for you client system(s). Do a search in the Linux Gazette archives for several discussions on this.
When you are getting free software and free support, it's important to do your homework. I typically will put about 10 hours into trying to solve a problem before I'll write up a question to post to the newsgroups, mailing lists, authors/maintainers, etc.
Of course I can understand part of the problem you might be facing. It sounds like you have little or no Linux experience, or at least little or no experience in setting up Linux networking.
You probaby don't know all of the elements that go into "telnetting into your server." Here's the basic rundown:
You have to have a client (telnet command). That has to be on a system with TCP/IP installed, configured and working. It must have an IP address and a route to your server.
You have to have a server (in.telnetd). It would normally be launched on demand by a dispatch program (inetd) which would be reading configuration out of a configuration file (/etc/inetd.conf).
On Linux systems the /etc/inetd.conf is usually configured to run most programs under an access control and logging utility called "TCP Wrappers" (/usr/sbin/tcpd). That utility refers to a couple of configuration files (/etc/hosts.allow, and /etc/hosts.deny) and it does some "paranoid" consistency checking to try and ensure that the client "is who he claims to be." The specifics of this paranoid checking are referred to as a "double reverse DNS lookup."
This requires that the client system's IP address somehow be registered in some sort of naming service that the server is configured to query. The easiest of these in most cases is to simply add the appropriate IP address (and some arbitrary name) int the /etc/hosts file. A better way is to add an appropriate PTR record to your DNS zone.
Linux uses a modular name services resolution system. Newer versions of Linux use the /etc/nsswitch.conf files to control the list of name services that are used for each name space (users/accounts, groups, hosts and networks, services, mail aliases, file server maps, etc). In most cases you wouldn't have to modify the nsswitch.conf to make it look at the /etc/hosts file. In other cases you might.
In previous months I've gone into greater detail about how to troubleshoot problems in accessing TCP services on Linux systems. Look for references to tcpdump and strace to find out more.
(Summary: You can replace the entry in /etc/inetd.conf with a wrapper script that runs 'strace' on the program, thus logging what the program is trying to do in great detail. You can also run 'tcpdump' on any machine on the local LAN segment, seeing the traffic between your client and server in great detail).
Unfortunately these tools are rather advanced, very powerful and coresponding difficult to use effectively. (You can probably get the information from them pretty easily -- the problem is to configure them to provide just the info you need and in parsing and understanding what they tell you).
Hopefully I've guessed correctly on what you problem is. Otherwise search through my back issues and the FAQ and do lots of troubleshooting. Ask a more detailed question.


Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 54 June 2000
HTML transformation by Heather Stern of Tuxtops, Inc., http://www.tuxtops.com/


[ Answer Guy Current Index ] greetings   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18 [ Index of Past Answers ]


[ Prev ] [ Table of Contents ] [ Front Page ] [ FAQ ] [ Next ]