Need help telnetting into my Ubunto box

WindsorKnot · 05-23-2021, 09:27 PM

Hi fellas - pretty new to Linux over here; I have an ASUS Eee netbook running Ubuntu 14.04. I would like to learn a little C programming in my downtime and the devshed IDE and CodeBlocks both hurt my eyes; meanwhile the netbook's keyboardette hurts my hands. :/

So I want to configure Telnet service on the netbook so I can use the vi editor and the gcc compiler from my physically-comfier HP laptop. (Telnet's security deficiencies are a non-issue because this is a self-contained three-node network in my home; it does not connect to the Internet.)

I followed the instructions here to get the telnet service installed and running

http://jdav.is/2018/04/22/installing...-ubuntu-linux/

I have verified a successful IPv4 connection between the netbook and my Windows laptop via crossover Ethernet cable and ping test.

When I did the "ss -tnlp" command I get two sets of output under the headers State, Recv-Q , Send-Q,Local Address:Port, Peer Address:Port

LISTEN 0 128 127.0.0.1:631 *:*
users:(("cupsd",1872,11))
LISTEN 0 128 ::1:631 :::*
users:(("cupsd",1872,10))

so... confused about this. What is :631 doing there when /etc/services clearly shows telnet on port 23; Why does that second line look like maybe an IPv6 address in which case that loopback is the only IPv4 addy in the picture even though there's a healthy IPv4 link on eth0 (192.168.1.1/24).

From my Windows command line I try

telnet 192.168.1.1

and I get

Connecting To 192.168.1.1...Could not open connection to the host, on port 23: Connect failed

What else needs doing to get the telnet service up and running and connectable-to on my li'l ol Netbook?

Thanks :)

michaelk · 05-23-2021, 09:56 PM

Port 631 is cups i.e. the print spooler and by default only listens to localhost i.e 127.0.0.1.
It does not look like your telnet server is running. Have you checked the firewall if running to allow telnet.

Anything you can do with telnet you can do with ssh which should just work but you still might have to allow ssh traffic through the firewall.
Download PuTTy and create a shortcut on your Windows desktop.

mrmazda · 05-23-2021, 10:26 PM

Are *inetd and telnet.socket enabled server-side?

WindsorKnot · 05-23-2021, 10:54 PM

Quote:

Originally Posted by michaelk

Port 631 is cups i.e. the print spooler and by default only listens to localhost i.e 127.0.0.1.
It does not look like your telnet server is running. Have you checked the firewall if running to allow telnet.

Anything you can do with telnet you can do with ssh which should just work but you still might have to allow ssh traffic through the firewall.
Download PuTTy and create a shortcut on your Windows desktop.

Yeah ssh is great but these telnet roadblocks strike me as a learning opportunity!!

Quote:

Originally Posted by mrmazda

Are *inetd and telnet.socket enabled server-side?

Well I googled how to check if *inetd is enabled, best I can do for you there is

Code:

root@ONCELER:~# ps aux | egrep '[xi]netd'
root      1045  0.0  0.0   2580   896 ?        Ss   20:15   0:00 /usr/sbin/xinetd -dontfork -pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root@ONCELER:~#

also tried this command, for naught :/

Code:

root@ONCELER:~# netstat -tulpn | grep LISTEN | egrep '[xi]netd'
root@ONCELER:~#

Googling "telnet.socket" seemed more of a needle in a haystack type endeavor...

mrmazda · 05-23-2021, 11:07 PM

# systemctl status unit.

scasey · 05-23-2021, 11:17 PM

Code:

root@ONCELER:~# netstat -tulpn | grep LISTEN | egrep '[xi]netd'
root@ONCELER:~#

Um. netstat -tnlp Is only going to return lines containing LISTEN (try it). You’re looking to see of telnet is listening, not x/itnetd.

Generally speaking one shouldn’t filter (grep) the output of a command unless one knows what the unfiltered output is. Do things in steps.

WindsorKnot · 05-23-2021, 11:27 PM

Quote:

Originally Posted by mrmazda

# systemctl status unit.

Aha.

Code:

root@ONCELER:~# systemctl status telnet.socket
telnet.socket
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)

root@ONCELER:~#

So this here seems to indicate something for which the fix is... ?

(And, again, :/ )

syg00 · 05-24-2021, 12:52 AM

Quote:

Originally Posted by WindsorKnot

Yeah ssh is great but these telnet roadblocks strike me as a learning opportunity!

More like an exercise in frustration. Might be worth learning about systemd and conversion of init scripts. I can't believe anyone would subject themselves to this for telnet in 2021.

mrmazda · 05-24-2021, 02:05 AM

Ubuntu 20.04's telnet offerings are confusing (to me at least):

Code:

# inxi -Sy
System:
  Host: host1 Kernel: 5.4.0-73-generic x86_64 bits: 64 Console: tty pts/0
  Distro: Ubuntu 20.04.2 LTS (Focal Fossa)
# aptitude search telnet | grep -v i386
p  dcap-tunnel-telnet		- Telnet tunnel for dCache
p  inetutils-telnet		- telnet client
p  inetutils-telnetd		- telnet server
p  libnet-telnet-cisco-perl	- Additional functionality to automate Cisco management
p  libnet-telnet-perl		- Perl module to script telnetable connections
p  libtelnet-dev		- Small library for parsing the TELNET protocol - development files
p  libtelnet-utils		- Small library for parsing the TELNET protocol - utilities
p  libtelnet2			- Small library for parsing the TELNET protocol - shared library
p  mactelnet-client		- Console tools for telneting and pinging via MAC addresses
p  mactelnet-server		- Telnet daemon for accepting connections via MAC addresses
p  ruby-net-telnet		- telnet client library
i  telnet			- basic telnet client
v  telnet-client		- 	
v  telnet-server		- 
p  telnet-ssl			- telnet client with SSL encryption support
i  telnetd			- basic telnet server
p  telnetd-ssl			- telnet server with SSL encryption support
# dpkg-query -l | grep telnet
ii  telnet	0.17-41.2build1	amd64	basic telnet client
ii  telnetd	0.17-41.2build1	amd64	basic telnet server
# systemctl list-unit-files | egrep 'inet|lnet'
inetd.service                          enabled
openbsd-inetd.service                  enabled

In Debian 10, from which Ubuntu derived, it's essentially the same:

Code:

# inxi -Sy
System:
  Host: host1 Kernel: 4.19.0-16-amd64 x86_64 bits: 64 Console: tty pts/0
  Distro: Debian GNU/Linux 10 (buster)
# aptitude search telnet
p   dcap-tunnel-telnet		- Telnet tunnel for dCache
p   inetutils-telnet		- telnet client
p   inetutils-telnetd		- telnet server
p   libnet-telnet-cisco-perl	- Additional functionality to automate Cisco management
p   libnet-telnet-perl		- Perl module to script telnetable connections
p   libtelnet-dev		- Small library for parsing the TELNET protocol - development fi
p   libtelnet-utils		- Small library for parsing the TELNET protocol - utilities
p   libtelnet2			- Small library for parsing the TELNET protocol - shared library
p   mactelnet-client		- Console tools for telneting and pinging via MAC addresses
p   mactelnet-server		- Telnet daemon for accepting connections via MAC addresses
p   ruby-net-telnet		- telnet client library
i   telnet			- basic telnet client
v   telnet-client		-
v   telnet-server		-
i   telnetd			- basic telnet server
# dpkg-query -l | egrep 'inet|lnet'
ii  openbsd-inetd	0.20160825-4	amd64	OpenBSD Internet Superserver
ii  telnet		0.17-41.2	amd64	basic telnet client
ii  telnetd		0.17-41.2	amd64	basic telnet server
ii  update-inetd	4.49		all	inetd configuration file updater
# systemctl list-unit-files | egrep 'inet|lnet'
inetd.service                          enabled
openbsd-inetd.service                  enabled

In openSUSE, it's vastly simpler:

Code:

# inxi -Sy
System:
  Host: host1 Kernel: 5.3.18-lp152.41-default x86_64 bits: 64
  Console: tty pts/0 Distro: openSUSE Leap 15.2
# zypper se -s telnet
...
   | perl-Net-Telnet | package | 3.04-lp152.3.2 | noarch | OSS
i+ | telnet          | package | 1.2-lp152.3.6  | x86_64 | OSS
i+ | telnet-server   | package | 1.2-lp152.3.6  | x86_64 | OSS
# systemctl list-unit-files | egrep 'inet|lnet'
telnet@.service                              static
xinetd.service                               enabled
telnet.socket                                enabled

Fedora's essentially the same as openSUSE:

Code:

# inxi -Sy
System:
  Host: host2 Kernel: 5.11.19-300.fc34.x86_64 x86_64 bits: 64
  Console: tty pts/0 Distro: Fedora release 34 (Thirty Four)
# rpm -qa | egrep 'lnet|inet'
xinetd-2.3.15-34.fc33.x86_64
telnet-server-0.17-83.fc34.x86_64
telnet-0.17-83.fc34.x86_64
# systemctl list-unit-files | egrep 'inet|lnet'
telnet@.service                            static          -
xinetd.service                             enabled
telnet.socket                              enabled

Mageia seems to be simpler still:

Code:

# inxi -Sy
System:
  Host: host3 Kernel: 5.10.19-desktop-1.mga8 x86_64 bits: 64
  Console: tty pts/0 Distro: Mageia 8 mga8
# rpm -qa | egrep 'lnet|inet'
netkit-telnet-0.17-20.mga8
xinetd-2.3.15.4-3.mga8
perl-Net-Telnet-3.40.0-8.mga8
netkit-telnet-server-0.17-20.mga8
# systemctl list-unit-files | egrep 'inet|lnet'
xinetd.service                          enabled

In all five of the above installations, telnet server is working as expected.

michaelk · 05-24-2021, 05:15 AM

No fix necessary, telnet server runs via xinetd in this case so there isn't going to be a systemd service unit nor will creating one help.

Learning xinetd might be a good experience but I don't think any distribution installs it by default anymore. Most services are standalone these days so it isn't needed.

A good teacher should instill learning good habits...

That said, it's probably not enabled to run.

WindsorKnot · 05-24-2021, 05:31 PM

At first I couldn't enable xinetd because I wasn't root; and damned if I could find the procedure for setting the root password on an Asus Eee. Months later that info finally appeared on the net and I was so jazzed to be able to make the configuration changes to get xinet and therefore telnet services finally running.

Then the 30,000+ post gurus here tell me setting up telnet is too difficult.

So I use ssh, it works just fine and the service had been running all along in the first place.

Sigh.

But now, on to get some C learning done.

michaelk · 05-24-2021, 05:46 PM

xinetd is not that difficult.

The point is telnet is deprecated and there is really no good valid reason to use it instead of ssh even if your network is isolated from the internet.

pan64 · 05-25-2021, 05:47 AM

Quote:

Originally Posted by michaelk

xinetd is not that difficult.

The point is telnet is deprecated and there is really no good valid reason to use it instead of ssh even if your network is isolated from the internet.

I agree, but [anyway] telnet exists and can be enabled (and disabled) - if xinetd was installed. That is documented for example here: man xinetd

syg00 · 05-25-2021, 08:12 AM

Quote:

Originally Posted by WindsorKnot

... gurus here tell me setting up telnet is too difficult.

Those who insist on tilting at windmills rarely accept that it is pointless.

BoraxMan · 06-13-2021, 07:20 PM

Do a "service xinetd restart" and run
journalctl -xe

Any errors?

I think there is an error in the instructions in that link. For my Debian 10 installation there is no /etc/inetd.conf, it is /etc/xinetd.conf

My setup is this, in /etc/xinetd.d/ I have a file called "telnet" with the following contents.

in /etc/xinetd.conf, this line is at the end

includedir /etc/xinetd.d

# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}

Lastly, you MAY need to add to /etc/hosts.allow your internal network IP address range.

Be sure not to expose telnet to the outside world!