Dust off that telnet command and communicate with a server
with raw plain-text commands—it’s good for the soul.
Poor telnet, it used to be the cool
kid on the block. It was the program
all sysadmins turned to when they
needed to connect to a remote server.
Telnet just wasn’t that good at keeping
a secret—all communication went over
plain text—so administrators started
switching to SSH for encrypted remote
shell sessions. Of course, along with
the switch came a huge stigma against
administrators who still used telnet.
Eventually, telnet became an outcast—
the program you used if you were an
out-of-touch old-timer who didn’t care
I for one think telnet isn’t all bad.
Sure, it can’t keep a secret, but it still
can do a lot of useful things around the
server room. Really, telnet just provides
you a convenient way to connect to a
network port and send commands. Telnet
can work well to diagnose problems
44 / SEPTEMBER 2012 / WWW.LINUXJOURNAL.COM
with one of the many services out there
that still accept plain-text commands
in their protocol. In fact, it’s one of my
go-to command-line programs when
I’m troubleshooting. In this column, I’m
going to give telnet a second chance and
describe how to use it to perform some
common troubleshooting tasks.
Test Remote Ports
There are many different ways to test
whether a network port is listening on
a system, including GUI port scanners,
Nmap and nc. Although all of those
can work well, and even I find myself
using Nmap more often than not, not all
machines end up having Nmap installed.
Just about every system includes telnet
though, including a lot of embedded
systems with BusyBox environments. So if
I wanted to test whether the SMTP port
(port 25) was listening on a server with