[SATLUG] connections refused
Chuck
Chuck at Tetlow.Net
Thu Aug 15 12:05:02 CDT 2002
Lets take this one step at a time and in a logical order. WARNING: I'll
provide ALL the instructions needed and this could get long...
First, checking /etc/services has nothing to do with Telnet'ing in or out.
It is merely a list of ports and the services that use a particular port
(like a directory). True, some services won't start up properly without an
entry in /etc/services -- but the file has nothing to do with configuration
of the servers. So, lets use "netstat -a |more" to check for a server
listening for Telnet connections. Its output will look something like:
[root at Server xinetd.d]# netstat -a |more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:netbios-ssn *:* LISTEN
tcp 0 0 *:http *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:https *:* LISTEN
udp 0 0 server:netbios-ns *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 server:netbios-dgm *:*
udp 0 0 *:netbios-dgm *:*
That fourth line tells me that my server is listening for telnet
connections. If you have this, your server is listening correctly and we
need to check access controls to see why it won't let you in. That problem
could be in the /etc/hosts.allow and /etc/hosts.deny files. Insert the line
"telnet.d:ALL" at the top of the /etc/hosts.allow file to see if it corrects
the problem. If it does, you will probably want to refine that rule a bit
to control who can connect to you with telnet -- but that's another story.
The second possibility at that point is that your firewall software is
blocking telnet connections (good possibility). Check your firewall rules
with the command "ipchains -L |more" or "iptables -L |more" depending on
whether you are using IPChains or IPTables. The output will look something
like:
[root at Server etc]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
which means there are NO firewall rules and the problem is elsewhere, or it
will look like:
[root at home /root]# ipchains -L
Chain input (policy ACCEPT):
DENY udp ----l- anywhere anywhere any ->
imap3
DENY tcp ----l- anywhere anywhere any ->
telnet
DENY tcp ----l- anywhere anywhere any ->
nntp
DENY tcp ----l- anywhere anywhere any ->
whois
DENY tcp ----l- anywhere anywhere any ->
finger
Line 2 in that output shows me that IPChains is blocking Telnet access on
the "input" chain. That means that inbound connections to this box will be
blocked. If you have a rule blocking Telnet (whether IPChains or IPTables),
delete the rule(s). Use the command "ipchains -D input 2" where input is
the chain name and the number 2 is the number of the line in the output
(count down the lines to the one you want to delete). If you in fact have a
firewall blockage, this should fix it.
But way back when we did the "netstat -a", if you DID NOT show listening for
Telnet connections -- we need to see why you aren't listening. First, we
check to see if you have the software installed for accepting Telnet
connections. Use the command "rpm -qa | grep telnet". My RedHat 7.2
machine provides the output:
[root at Server etc]# rpm -qa | grep telnet
telnet-0.17-20
telnet-server-0.17-20
If you don't get that output, you first have to install the software --
because you don't have it. Put your RedHat CDs into your drive one at a
time and look in the <cdrom>/RedHat/RPMS directory for those file names.
When you find the, install with "rpm -i telnet-server.0.17-20" and "rpm -i
telnet-0.17-20". After that, you might have to do some of the other checks
we've gone over on this page. But at least you have the software installed
at that point.
If you do get that output and have the software installed, we need to check
the xinetd daemon configuration. Go to the /etc/xinetd.d directory and look
for a file named "telnet". Its contents should look like:
[root at Server xinetd.d]# cat telnet
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
If the last entry has disable = yes, just change that to no. Now, restart
the xinetd daemon and you are off and running. Do that by first getting its
process ID (PID) with "cat /var/run/xinetd.pid" (it will be a number). Then
use the command "kill -HUP ###" with the ### equal to the PID number.
That's it. You have everything you need in these instructions to get
inbound Telnet connections working. As for outbound, you just need to have
that "telnet-0.17-20" package installed to do outbound Telnets (as long as
the firewall isn't blocking them).
Good luck.
Chuck
P.S. - Looking in the netstat output for ssn tells you that your Microsoft
Networking is listening. SSN is the "Netbios session service" part of the
MS protocol.
-----Original Message-----
From: satlug-admin at satlug.org [mailto:satlug-admin at satlug.org]On Behalf
Of G. D. Abernathy
Sent: Thursday, August 15, 2002 7:28 AM
To: satlug at satlug.org
Subject: [SATLUG] connections refused
I have installed RH 7.1 with samba and a web set up. When I attempt to
connect from another machine, the connection is refused. I can ping
and ftp to and from the box but Telnet does not work either, in or out.
I have checked the /etc/services files and the appropriate ports are
open. Netstat reveals that ssn is in a listen state. I know that I
must be overlooking something simple, any ideas? TIA
gda
_______________________________________________
Satlug mailing list
Satlug at satlug.org
http://alamo.satlug.org/mailman/listinfo/satlug
More information about the Satlug
mailing list