Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Can't telnet myself

786 views
Skip to first unread message

Florian Lorenzen

unread,
Aug 1, 1999, 3:00:00 AM8/1/99
to
Hi,
I tried had to telnet myself but the telnet client message is
"connection refused". I've checked all entries in hosts.allow and
hosts.deny, enabled the inetd-service for /usr/sbin/tcpd in.telnetd and
couldn't find the problem. I've as well restarted the servers few times
that changes could take effect.
Does anyone know, which configuration-file might be the problem?

Florian

Ömer Uyar

unread,
Aug 1, 1999, 3:00:00 AM8/1/99
to
Check that you have the 127.0.0.1 localhost record in your /etc/hosts.deny
or /etc/hosts.allow files.
Florian Lorenzen wrote in message <37A45E06...@hgmp.mrc.ac.uk>...

W.G. Unruh

unread,
Aug 1, 1999, 3:00:00 AM8/1/99
to
Florian Lorenzen <flo...@hgmp.mrc.ac.uk> writes:
>I tried had to telnet myself but the telnet client message is
>"connection refused". I've checked all entries in hosts.allow and
>hosts.deny, enabled the inetd-service for /usr/sbin/tcpd in.telnetd and
>couldn't find the problem. I've as well restarted the servers few times
>that changes could take effect.
>Does anyone know, which configuration-file might be the problem?

Look in the log files to see if there are any messages hinting why the connection
was refused. Eg, /var/log/messages, /var/log/secure. Make sure you have
daemon.* /var/log/messages
in /etc/syslog.conf and do
killall -1 syslogd


Florian Lorenzen

unread,
Aug 2, 1999, 3:00:00 AM8/2/99
to

If in /var/log/messages are no lines relating to tcpd or inetd or
in.telnetd. But in /var/log/secure I found the following lines:

Jul 31 17:48:56 praesodymium tcpd[422]: warning: can't get client
adress: Socket operation on non-socket
Jul 31 17:48:56 praesodymium tcpd[422]: warning: /etc/hosts.allow, line
8 missing newline or line too long
Jul 31 17:48:56 praesodymium tcpd[422]: warning: /etc/hosts.deny, line
10: missing newline or line too long
Jul 31 17:48:56 praesodymium tcpd[422]: connect from unknown

I've tried to alter the format in hosts.allow and hosts.deny, added some
newlines etc., my files now look like this

hosts.allow
# some comment in this area
#
#
#
#
#
#
ALL: ALL

hosts.deny
# some comment in this area
#
#
#
#
#
#
#


There are now hosts denied in this file.

Quite a dangerous configuration but I have just a LAN of two hosts not
connected to th Internet.

As I said, I still got the message:

# telnet 127.0.0.1
Trying 127.0.0.1...
telnet: Unable to connect remote host; Connection refused

Then I tried to de-activate tcpd for telnet by adding the following line
in /etc/inetd.conf

telnet stream tcp nowait root /usr/sbin/in.telnetd

and de-activating the line with tcpd in it.

But still, the connection was refused. Is there any other file that
could interfere?

When I tried to start /usr/sbin/in.telnetd by hand the following message
appeared

/usr/sbin/in.telnetd: getpeername: Socket operation on non-socket

What does this mean. Might something with my network-configuration be
wrong?

By the way, I've running Apache on the Linux-box and can access it from
the other (Win)-host, so somehow, the network works, but perhaps is
something wrong I don't know about.

Thanks

Florian

Lindoze 2000

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
I've never tried to telnet to myself before.
wow imagine being able to telnet to myself...then
I can be remote controlled! Just imagine...

does your network work?
type this:
ifconfig eth0 123.211.212.12 up <----choose your own IP addy.
then ping 15.65.45.45 < -- some remote IP


Florian Lorenzen wrote:
>
> Hi,


> I tried had to telnet myself but the telnet client message is
> "connection refused". I've checked all entries in hosts.allow and
> hosts.deny, enabled the inetd-service for /usr/sbin/tcpd in.telnetd and
> couldn't find the problem. I've as well restarted the servers few times
> that changes could take effect.
> Does anyone know, which configuration-file might be the problem?
>

> Florian


--
Thank you for your valuable input. Your useful answers will benifit
other users as well.
You are Linux!

########################################################
## ##
## My Experiment ##
## http://www.FusionPlant.com ##
## ##
########################################################

Florian Lorenzen

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
Well, the sense of telnetting myself is just to test whether my network,
inetd and tcpd-daemons work.
I can ping other hosts and I can ping myself, and I can access the
Apache running on my Linux-box from other hosts of my network and from
the Linux-box itself. But this all I can do, I can't ftp myself or from
antoher host and I can't access the nameserver with nslookup. What I
suspect is, that lots of ports are locked for some reason. And I don't
know how to fix that.

Florian

Thomas Zajic

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
On Tue, 03 Aug 1999 11:20:02 +0100, Florian Lorenzen wrote:

> Well, the sense of telnetting myself is just to test whether my network,
> inetd and tcpd-daemons work.
> I can ping other hosts and I can ping myself, and I can access the
> Apache running on my Linux-box from other hosts of my network and from
> the Linux-box itself. But this all I can do, I can't ftp myself or from
> antoher host and I can't access the nameserver with nslookup. What I
> suspect is, that lots of ports are locked for some reason. And I don't
> know how to fix that.

Are you sure that your /etc/hosts.{allow|deny} are set up
properly? This can be tricky at times ... try checking your
setup with 'tcpdcheck' and 'tcpdmatch', they are part of the
TCP wrappers distribution (in Slackware, they live in
/usr/sbin/real-daemon-dir). If 'tcpdcheck' reports errors,
have a look at 'man 5 hosts_access' and 'man 5 hosts_options'.

HTH,
Thomas
--
=--- Thomas Zajic aka ZlatkO ThE GoDFatheR, Vienna/Austria ---=
=-- "It is not easy to cut through a human head with a hacksaw." M.C. --=
=-- Posted with Free Agent 1.11/32 running on Linux 2.0.37/Wine-990731 --=
=--- Spam-proof e-mail: thomas(DOT)zajic(AT)teleweb(DOT)at ---=

Rudolf Potucek

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
I wouldn't assume you played with firewalling, but I noticed some really
odd stuff happening when I (accidentally) dropped all the packets on the
lo device ... oops! So you might want to check

>ifconfig lo

to make sure it's there and running (I don't understand why, but you can
actually disable it in a kernel compile ...).

Rudolf

Thomas Zajic
(NO-thom...@teleweb.at-SPAM)

--

Florian Lorenzen

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
Where do I get tcpdcheck from, it's not included in my RH 5.2
tcp_wrappers-package.
Can I download it somewehere?
By the way, tcpdmatch, started with

> tcpdmatch in.telnetd 127.0.0.1

made the following output:

client: adress 127.0.0.1
server: process in.telnetd
matched: /etc/hosts.allow line 9
access: granted.

That doesn't seem wrong to me at all, neverthelesse, I can't telnet
myself. So, something must be wrong, with my network-configuration.

Perhaps, somebody knows something else.

Thanks.

Thomas Zajic

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
On Tue, 03 Aug 1999 18:20:53 +0100, Florian Lorenzen wrote:

> Where do I get tcpdcheck from, it's not included in my RH 5.2
> tcp_wrappers-package.
> Can I download it somewehere?

Sorry, it was a typo - it's actually called 'tcdpchk'. If
it's really missing, you can download the TCP Wrappers from
here:

ftp://ftp.porcupine.org/pub/security/

This is in .tar.bz format BTW, if you need a Red Hat .rpm
then check at your "usual places".

> [ ... ]


> That doesn't seem wrong to me at all, neverthelesse, I can't telnet
> myself. So, something must be wrong, with my network-configuration.

Strange. Follow the advice of the previous poster, ie.
make sure that your "lo" interface is up & running,
and double-check your firewall rules, if any.

Good luck,

Thomas Zajic

unread,
Aug 3, 1999, 3:00:00 AM8/3/99
to
On Tue, 03 Aug 1999 18:41:03 GMT, Thomas Zajic wrote:

> Sorry, it was a typo - it's actually called 'tcdpchk'. If

Damn, it's not my day today - let me try again, maybe
without a typo for a change: 'tcpdchk'. So there. ;-)

Florian Lorenzen

unread,
Aug 4, 1999, 3:00:00 AM8/4/99
to
Hi,

I answer my own question, just in case somebody else has the same
problem.

As (nearly) always, the solution was absolutely trivial. I wanted to
start the in.telndetd-server with the inetd-super-server. All conf-files
(inetd.conf, hosts.allow and hosts.deny) were o. k., inetd and
in.telnetd were in usr/sbin wre they should be. But all this works of
course only, if the inetd-daemon is loaded. In my configuration there
was no symbolic link for /etc/rc.d/init.d/inetd in /etc/rc.d/rc3.d, so
inetd wasn't invoked in my default runlevel 3.
Pretty simple, hu?

Florian

Florian Lorenzen

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
I read your post on comp.os.linux.networking about making a symbolic
link in /etc/rc.d/rc3.d for ../init.d/inetd to make telnet to the linux
box work. I had a few questions, I was wondering if you can help me out.

First, all the symbolic links in the directory have funny looking
prefixes, like S90sendmail or ssomething like that, if I were to make a
symbolic link how do I know what to name the link (i.e., what prefix
should I add to it?)

Second, inetd does not exist in /etc/rc.d/init.d for me! There is some
kind of script file in there called inet, however, which seems to have
something to do with inetd, but I am not sure. What should I do?

Thanks,

Mike
(oh, please reply to mike...@hamon.swmed.edu, email is not 100% working
on this linux box yet either ;\)

Florian Lorenzen

unread,
Aug 13, 1999, 3:00:00 AM8/13/99
to
Hi Mike,

the purpose of these links in /etc/rc.d/rc3.d and the other rcX.d
subdirectories of rc.d is to procvide a link to the corresponding
scripts in /etc/rc.d/init.d. When the runlevel changes, i. e. the mode
that the system is running in (e. g. single user mode, shutdown-mode,
restart-mode etc.), a script calles /etc/rc.d/rc looks in the
corresponding runlevel-directory and executes the links. So, if your
system starts runlevel 3 at bottup, alle the links in r/etc/rc.d/rc3.d
are executed. The funny prefixes sa the following: if ist an SXX, it
means this service has to be started, if it is KXX, it means, this
service has to killed. The numbers, I represented with XX, say in what
sequence the services have to started, because it's sometimes important,
that one service is started before or after another because it relies on
this particular service. An example to illustrate this: If you want to
start a web-server, you should start the networking-services before etc.

If you now want to start inetd, the Internet-services-super-server, you
have to make a link to the script /etc/rc.d/init.d/inet. inet should be
provided with your distribution and is just a script that can start,
stop or restart the inetd-server.

In order to make the link, execute the follwing command:

ln -s /etc/rc.d/init.d/inet /etc/rc.d/rc3.d/S50inet

You have to look, what S-number your network-service has. In my
distribution (RedHat 5.2) it is S10network, so S50 for inetd is o. k.

If you have no inet-script in your /etc/rc.d/init.d-directory, first
check, whether inetd is installed in /usr/sbin. Then you can make up the
script by hand. Just send me another e-mail, then I canm send you my
inet-script as a template.

The thing about these services is, that they have to be stopped again.
So, in order to have a correctly working system, you have to make up
K-links to the inet-script in the directories /etc/rc.d/rc0.d,
/etc/rc.d/rc1.d, /etc/rc.d/rc6.d. inetd should be stopped, before
networking is shut down, so have a look at the number of the KXXnetwork
link in these directories.

This was quite a bunch of theory about the init-sequence of a
Unix-like-system. I hiope it was o. k. for you.

There might be as well other problems, if you want to telnet yourself in
order to check whether your networking is running or not. These might
include improper entries in /etc/services, /etc/inetd.conf,
/etc/hosts.allow and /etc/hosts.deny. Another problem might be, that
tcpd is not installed in /usr/sbin or that in/telnetd (the
telnet-daemon) is not installed in /etc/sbin. Check this first.

But first of all (sorry, that I write it that late), check whether your
inetd is running or not. Just type (as root)

ps -aux | more

There will appear a list if processes running on your system, if inetd
is listed, you don't have to worry about all these links in ther
rcX.d-directories.

Just try

telnet localhost

and normally you should get your own login. Don't do this a s root,
because you're normally not allowed to telnet-login as root. You would
have to modify some files first, but I admit, I don't know which ones.

Just try the things I've described above and probably you'll get what
you want. If not, just send me another e-mail whith the error messages
and a describtion what you've done. Perhaps I can help you then.

Florian

PS. You didn't send your message to the newsgroup, did you? It's better
to send it to the newsgroup than just to me because then other people
can learn from it, too. So, I just put your message and my answer in
there, perhaps, you get answers from other people as well.

0 new messages