Although Unix and Linux servers today use ssh rather than telnet, telnet is not at all dead. In fact, it's an important networking testing tool because it is, if not quite ubiquitous today, at least easy to obtain.
Sometimes I'll get the response: "But we don't have telnet enabled on the server". More surprising to me was that at least
some of these were from people I thought would know better: that is, they knew
that adding a port number at the end of the telnet made it contact a different
port. Apparently the confusion was elsewhere: they thought that a telnet program would be answering this request, noticing the different port number,
and forwarding the traffic to something else (which is actually exactly
what inetd and xinetd do, of course). Complicating things further,
one explained that he knew inetd would be handling the request, but he still
thought that telnet had to be running on the server because the origin
of the connection was by telnet.
Actually, the answering daemon has no clue what program created the connection request it is talking to. Whether it was telnet, nc, Outlook Express
or another smtp server is completely unimportant and completely unknown.
Well, that's not completely true: it's vaguely possible that an
answering daemon might hazard a guess based on heuristic analysis
of how the other end makes requests, and a packet sniffer might make even
better guesses based on packet header information, but that's all
pretty esoteric and meaningless in this context.
It's always interesting to see how people have constructed an incorrect
view of how something works. All of us have our own fuzzy areas
where knowledge blends with invention and wishful thinking.
Let's just mention "nc"
I said that telnet is an important network testing tool. Anyone who knows a little bit about "nc" might take issue with that. It's true: nc is a powerful tool and telnet is, well, just telnet.
You could use "nc" in that mailserver test above: "nc mailserver 25" (if you have trouble with that, try ""nc -C mailserver 25" or see telnet vs. netcat).
But, do you have nc? You can get it for Windows, but telnet is already there.
Telnet on Windows
Vista and Win 7: Microsoft includes but disables the telnet client on these operating systems. To correct that stupidity:
Open Control Panel -> Programs
Click "Turn windows features on or off" . On the list that appears, check the box "Telnet Client"
Click OK. You now have "telnet"
It's the same for Windows * except that you need the Desktop Control Panel - you can get to that from "More Settings" after clicking on the Control Panel icon.
You could also use a Software Terminal emulator. The list at that link includes both free and commercial terminal emulators for Windows.
Windows 95 issue
Gosh, I hope you aren't still running Windows 95, but I'll mention this just in case: that telnet didn't understand IAC-DM (see Telnet Protocol), which can be sent by a telnet server.
Little things like that can cause problems for naive attempts to create network utilities.
Other Windows emulation issues
I've seen terminal emulation software that was dependent upon a specific WINSOCK.DLL.
Personally, I dislike colorization. Aside from personal preferences, bad
or incomplete terminal emulation can make things very unpleasant.
Telnetting from a SCO Unix machine can really be messy. Try this:
Immediate fix: Type your telnet escape character (probably
CTRL-] ) and then type:
You should also be able to do "unalias ls" at he Linux console to shut this off ls colorization.
Or, before telnetting from a SCO console, run
That shuts off color and about the worst you will get is bold
characters. Remember- you do the vidi on the SCO side BEFORE you
telnet or ssh to Linux.
Put it back to normal with
Another trick is to have previously done:
setcolor -n > resetc
on the SCO box. Transfer that "resetc" file to Linux, and when
things become ugly, "cat resetc" will restore colors.
If you are using ssh, and have started from a job-control shell,
you are supposed to be able to type ~ followed by CTRL-Z to suspend
back to your original shell. This works fine on some systems, but
not with my ORS5 box when logged in as "root"- I get back to my
starting point all right, but then "fg" lists no jobs. Hoewever,
using ksh as any other user, this works fine.
Linux systems today usually don't include telnetd (the telnet server daemon) by default. See Enable Linux Telnet if you need it (but you really should use ssh!).
Telnetd records unsuccessful logins in syslog. The actual message varies;
SCO Unix systems would say
telnetd[pid]: can't find user in the protected password database
If it's recurring, you either have someone trying to hack into your system
by trying to guess passwords (you'll get the same message in syslog
for an incorrect user name or a correct user name and incorrect
password) or some confused user.
The horrid SCO command:
userls -x unsuccessfulLoginAttempts
(which is completely unforgiving about capitalization) can help
you find out WHICH user is failing to login.
A stuck enter key (a book on the keyboard?) can cause entries in syslog also. A message like "can't find user in protected password database" on SCO could be someone trying non-existent logins or could be that carelessly placed book.
If you can't figure out what's causing it, try:
netstat -n -p tcp | grep '\.23 .*TIME_WAIT'
Just because we are talking about syslog, I'll mention "Cannot access terminal control database entry", which meant SCO's TCb (Trusted Computing Base) files were munged; a "ttyupd ; /tcb/bin/ale /etc/auth/system/ttys pttyupd" would usually fix that.
Another related log entry: "Warning: serial: garbage or loose cable on dev 9 port shutdown". In the days of serial terminals, that indicated a line problem.Which line? "ls -l /dev/tty*|grep ', 9 '" would tell you.
Telnet and ssh recognize "/etc/nologin" - nobody but root is allowed to login. Confusingly, the hapless user doesn't usually get told why (an admin might
"touch /etc/nologin" while doing maintenance) and seurity logs may just say "Authentication failure". I had that recently on a Linux system where a new admin followed directions left by his predecessor that included that command. Unfortunately the directions didn't include removing that file when the maintenance was complete!
Running Telnet on a different port
In the good old days, this was considered a security issue. Nowadays,
obfuscating ports for security reasons is almost pointless: the bad guys will
find open ports very quickly.
Modify /etc/services to change "telnet 23/tcp" to "telnet 4045/tcp" or whatever. If you want to also listen on another port, add a line like ""telnet 4045/tcp" to /etc/services and this to /etc/inetd.conf:
I had an email from a reseller who I have helped with
routers, vpn's etc. in the past. I usually set his clients up with
internet ssh access restricted to specific accounts (see Security Paranoia - restricting ssh access),
but apparently I had never explained WHY I do this, because his
email went something like this (edited slightly to remove
I had someone show me a trick the other
day...I was able to connect to his customer using ALPHACOM with a
I think the "!" is because he probably thought telnet over the
Internet was impossible. My fault for not explaining this stuff
better. He went on to say:
What he did is give me an IP address that I
plugged in and bingo, I got a login. What I had to do was go to the
advanced properties and give it a port number to use as well. This
is because on his router he set it up so that port xyz forwarded to
something like port 23 on the system.
Actually, it's "Bingo! You have a big security hole!".
The person who gave him this "trick" probably thought that by
using a different port he had improved security. That's called
"security through obscurity" and the only people it protects you
from are the ones that probably couldn't hurt you anyway. Anyone
else is going to scan a full range of ports and they will see your
login almost as quickly as they would had you left it at port
So there we are, telnet open to the world. Unless the firewall
has a rule that says "only folks from these addresses get
forwarded" (and if you had that, why obfuscate the port?), anyone
can try to log in. Anyone can TRY to login with ssh, too, but as
explained above, we only allow certain accounts to do that, and
root isn't one of them. So the attacker is free to hammer away,
guessing root passwords for as long as he wants.
Well, not quite. That version of SCO implements a feature to
lock out a tty after so many unsuccessful logins - usually set to
99, but it doesn't take all that long for a dictionary password
attack to hit that number. So, a pseudo tty gets locked out, and
now nobody can login (see /Detective/ttylocked.html).
Of course that assumes that the dictionary attack failed..but
dumb passwords are pretty common, and most people have no idea how
many of these guys try and how long they keep trying. I see it in
my server logs, and it is just incredible. Here's just a sample
Failed logins from these:
adm/password from 22.214.171.124: 2 Time(s)
apache/password from 126.96.36.199: 1 Time(s)
cyrus/password from 188.8.131.52: 1 Time(s)
horde/password from 184.108.40.206: 1 Time(s)
iceuser/password from 220.127.116.11: 1 Time(s)
irc/password from 18.104.22.168: 2 Time(s)
jane/password from 22.214.171.124: 1 Time(s)
matt/password from 126.96.36.199: 1 Time(s)
mysql/password from 188.8.131.52: 1 Time(s)
nobody/password from 184.108.40.206: 1 Time(s)
operator/password from 220.127.116.11: 1 Time(s)
pamela/password from 18.104.22.168: 1 Time(s)
patrick/password from 22.214.171.124: 2 Time(s)
rolo/password from 126.96.36.199: 1 Time(s)
root/password from 188.8.131.52: 11 Time(s)
test/password from 184.108.40.206: 4 Time(s)
www-data/password from 220.127.116.11: 1 Time(s)
www/password from 18.104.22.168: 1 Time(s)
wwwrun/password from 22.214.171.124: 1 Time(s)
Remember - I lock people out after 2 failed logins - so the ones
with more than that waited quite a while and came back at me again
and again! None of those accounts could login anyway - they aren't
in the ssh allowed users list - but they can't tell that, so they
keep on trying. Hour after hour, day after day.
Don't do this.
Telnet/FTP is very slow to connect
Slow telnet or ftp connections (Unix and Linux) are often caused by the server wanting to do a reverse DNS lookup to find out who is connecting.
If you aren't running DNS, you can fix this just by listing all the
machines in /etc/hosts. Note that you don't have to be accurate
about the names: I often use the ip adress with "_" substituted for
the "."'s, like "host_192_168_2_3" and so on. A simple script:
while [ $x -lt 255 ]
echo "192.168.2.$x host_$x"
x=$((x + 1 ))
done >> /etc/hosts
Almost ALL machines want to know who is connecting to them - Unix, Linux, Windows, whatever. If their DNS doesn't give a quick answer, anything trying to connect will be delayed.
SCO's 5.0.5 telnetd had Kerberos on by default, but not necessarily configured, causing clients to fail. The 5.0.6 telnetd fixed that. You could also try passing "-X KERBEROS_V5" or "-a off" to the telnetd startup.
In an old newsgroup post that I no longer have a link to, John Dubois explained:
The -X options disable authentications, but telnetd still requests to negotiate authentication. SCO's telnetd does this negotiation correctly - if negotiation is handled properly by the other end, telnetd will report that it "WONT" do authentication - but even the request to negotiate authentication is enough to break some buggy telnets. As a workaround for this, SCO's telnetd was modified so that '-a off' turns off any attempt at negotiation of authentication, as well as authentication itself. The modified telnetd appeared in 5.0.6.
Disable host information
Should you be running some telnet daemon that might be vulnerable to
exploit, you can probably add -h to its startup. Every telnetd I know recognizes that as "Disable the printing of host-specific information before login has been completed."
netdata and prettydump
If terminal commands aren't working properly, it can be helpful to see
what's actually going on. Use your telnet escape character ( probably CTRL-]) and then type:
telnet> set netdata
Will print hexadecimal representation of network traffic.
telnet> set prettydump
Will print user readable output for "netdata".
Telnet environment variables
Some exported variables are passed to your telnet session and people have sometimes exploited that for special needs. For example, you can pass information by embedding it in a passed variable. What's passed? Probably at least HOME, SHELL, DISPLAY, TZ and TERM, but see TELNET ENVIRON in your telnet man/info pages.
Another exploitable (in a good sense, we hope) thing is that the name of
the answering daemon is available in "ps". So, if you wanted to have another
telnetd (or whatever) running on a different port, you could call it "alt_telnetd" and that is the parent of a login that used it. Shrug - might be useful.
That may seem like a silly question. The answer is that it doesn't matter a bit to either, but it *might* matter to some ancient application. That's unlikely, but if you are running legacy software, it's a possibility.