7

The client PC IP: 10.49.46.5/24 and the server PC IP: 10.49.46.2/24 are two computers linked to the same network. When I try to create an interactive communication between these two computers using the command telnet, I get the following:

[root@xxx:~]# telnet 10.49.46.2
Trying 10.49.46.2...
Connected to 10.49.46.2.
Escape character is '^]'.

Connection closed by foreign host.
[root@xxx:~]#

The server xinetd.conf are as follows:

    defaults
    {
            instances               = 60
            log_type                = SYSLOG authpriv
            log_on_success          = HOST PID EXIT
            log_on_failure          = HOST ATTEMPT
            cps                     = 25 30
    }
includedir /etc/xinetd.d

The server telnet.config are as follows:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/telnetd
        log_on_failure  += USERID
        instances       = 10
        disable         = no
}

The TCPWrapper hosts.allow are:

telnetd: /etc/telnetd.hosts
tfdpd: /etc/tftpd.hosts
sshd: /etc/sshd.hosts

The TCPWrapper hosts.deny are:

ALL:ALL

NOW:

  1. I checked ssh and it is running on port 22.
  2. I checked /var/log/message and had found that the command xinetd starts and then exits the telnet immediately.
  3. I checked that iptables do not drop telnet package using the command: iptables -L

Would you please help me figure out what is the problem and how can I fix it?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Yuri
  • 71
  • 1
  • 1
  • 3
  • What's listening on the server side? – Kusalananda Sep 23 '17 at 08:39
  • At a guess, the default timeout on the remote server (say a webserver) was hit and the connection was disconnected. Copy your list of commands (or at least the initial connection command) to the clipboard and paste them as soon as the connection is established. – Tigger Sep 23 '17 at 09:13
  • @Tigger I updated my question – Yuri Sep 23 '17 at 09:35

4 Answers4

4
[root@xxx:~]# telnet 10.49.46.2
Trying 10.49.46.2...
Connected to 10.49.46.2.
Escape character is '^]'.

This means that you have successfully established a TCP connection to the remote daemon. What daemon? The xinetd one which serves as a hub. Now that you are connected, xinetd attempts to launch the specific service (telnet).

Connection closed by foreign host.

This means that launching the telnet service failed. You may want to add debugging options to the telnetd command line and read xinetd logs to see what exactly failed.

You appear to be running the BusyBox version of telnetd. Contrary to classic versions of telnetd, the one provided with Busybox is a standalone daemon which needs a -i option to interface with inetd (services launched by inetd have a specific interface incompatible with a standalone daemon: they must not open and listen to sockets, they must communicate with the client through stdin/stdout).

Your xinetd configuration should thus be:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/telnetd
        server_args     = -i
        log_on_failure  += USERID
        instances       = 10
        disable         = no
}
xhienne
  • 17,075
  • 2
  • 52
  • 68
  • The questioner _has_ been reading logs. What the log said is in the question. The questioner is _not_ launching `telnetd` as a standalone daemon. That, too, is in the question. The xinetd configuration snippet to launch `telnetd` is right there, as indeed is the fact that xinetd logged launching it. And the executable could be _either_ `telnetd` _or_ `in.telnetd`, neither name implying a standalone daemon. One implies GNU inetutils and other implies BSD telnetd, both launchable via (x)inetd. – JdeBP Sep 23 '17 at 12:41
  • @JdeBP Thanks, that's right that I didn't the OP carefully enough. I tried to address your points by amending my answer. – xhienne Sep 25 '17 at 22:27
  • @xhienne Yes, I use `BusyBox v1.25.0.git` (checked by `busybox | head -1` command) and linux kernel version: `4.0.0-xilinx-00007-g5dab41c-dirty` (checked by `uname -r` command). I changed telnet config file (`/etc/xinetd.d/telnet`) to add `-i` option as you mentioned (`server = /usr/sbin/telnetd -i`) but it had a new issue: `Connection refused`. I have stopped and started xinetd again but it's not different. – Yuri Sep 26 '17 at 02:55
  • @xhienne I tried with `server_args = /usr/sbin/telnetd -i`, nothing change :) – Yuri Sep 26 '17 at 06:41
  • @Yuri Connection refused means that the telnet service is not set up (misconfiguration I guess). The telnet port should be open and connection should be accepted, as in you original question. I don't have the Openwrt's xinetd manual at hand. However, the Debian version states "In contrast to inetd, the server name should **not** be included in server_args". Try with just `-i`. You may add `-l date` to the args for your tests: if the telnet daemon writes the date, your configuration is ok. – xhienne Sep 26 '17 at 22:57
0

specify the telnet port with telnet 10.49.46.2 24.

As per a Cognex camera manual, "supplying the port number disables the Unix username/password authentication and forces the Unix system to prompt you for a user name and password."

ptoot
  • 1
-1

xhienne makes some good points. The TCP handshake is completing. That the connection is then closed means one of 2 things.

1) The telnetd service is failing when it starts (check your logs)

2) the client you are connecting from is not listed in /etc/telnetd.hosts (check your logs, or rename /etc/hosts.deny temporarily to confirm)

The client IP: 10.49.46.5/24

No, IP host addresses don't have network masks.

And please stop using telnetd. Every time you telnet a kitten cries. (use ssh or telnet-tls)

symcbean
  • 5,008
  • 2
  • 25
  • 37
  • The TCP wrappers library is used by `inetd`, not by `telnetd`. Why would `inetd` start `telnetd` (as reported in the question) if your client is denied access by the `/etc/hosts.*` files ? – xhienne Sep 25 '17 at 22:32
  • @xhienne: no. TCP wrappers will be used by any daemon compiled against Weistse Venema's socket library, If telnetd is run as a daemon and linked to the library, it will use hosts.all/deny. inetd and xinetd are usually compiled against the library. /etc/hosts does not grant/deny access - its the the data file for file based host name service. The behaviour you describe (connect, then close) is entirely consistent with the behaviour of TCP wrappers. Its also consistent with a badly configured [x]inetd. Instead of arguing, would it be so hard to text? – symcbean Sep 25 '17 at 22:46
  • Not sure what you mean by "to text". If you don't want to argue, just don't elaborate on a `/etc/hosts` file that I didn't even mention and just answer my one and only question. OP states that `xinetd` starts telnet and exits immediately. `xinetd` has no reason to do so if your access is denied. – xhienne Sep 25 '17 at 23:47
  • Sorry typo - not text / test. – symcbean Sep 26 '17 at 09:28
  • "_host addresses don't have network masks._" they don't, but it's a very convenient useful and appropriate way of signifying the subnet mask. – roaima Dec 22 '18 at 13:09
-1

Try the command:

sudo apt install tcpd
AdminBee
  • 21,637
  • 21
  • 47
  • 71
Pb Solver
  • 1