All about Telnet

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.

But we don't use telnet!

When testing mail, I'll often have a customer do something like "telnet mailserver 25" or "telnet mailserver 110". The purpose, of course, is to do command line testing of smtp or pop (see How do I test a smtp connection?, How do I test an imap server? and How do I test a popd connection?)

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.

Windows Emulators

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.

Linux Colorization

Personally, I dislike colorization. Aside from personal preferences, bad or incomplete terminal emulation can make things very unpleasant.

To fix vim colors, see Controlling Linux colors in vi (vim).

Telnetting from a SCO Unix machine can really be messy. Try this:

Immediate fix: Type your telnet escape character (probably CTRL-] ) and then type:

 !setcolor -n

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

vidi vm80x25

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

vidi v80x25

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.


Telnetd server

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 /var/adm/syslog:

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.

If you have some other reason for doing this:

inetd systems

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:

(SCO) telnet2 stream  tcp     nowait  NOLUID  /etc/telnetd    telnetd
(AIX) telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a
(Older Linux) telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

Most Linuxes don't use inetd any longer. You may have /etc/xinetd.d/telnet:

service telnet 
disable = yes 
socket_type = stream 
wait = no 
user = root 
server = /usr/libexec/telnetd 
groups = yes 
flags = REUSE 

Systems using Upstart start services with .conf files in /etc/init (NOT /etc/init.d!).


If you MUST run telnetd, consider allowing it only through a vpn. You should also consider not allowing root to login at all.

Here's an example of why:

Why you don't have telnet open to the world

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 extraneous material):

I had someone show me a trick the other day...I was able to connect to his customer using ALPHACOM with a TELNET session!

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 23.

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 2 Time(s)
apache/password from 1 Time(s)
cyrus/password from 1 Time(s)
horde/password from 1 Time(s)
iceuser/password from 1 Time(s)
irc/password from 2 Time(s)
jane/password from 1 Time(s)
matt/password from 1 Time(s)
mysql/password from 1 Time(s)
nobody/password from 1 Time(s)
operator/password from 1 Time(s)
pamela/password from 1 Time(s)
patrick/password from 2 Time(s)
rolo/password from 1 Time(s)
root/password from 11 Time(s)
test/password from 4 Time(s)
www-data/password from 1 Time(s)
www/password from 1 Time(s)
wwwrun/password from 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.

Understand that being slow to give up on name resolution is an annoyance on small networks and a Good Thing on large networks. Systems that give up quickly work well on small networks, but don't get the information they should have on larger nets.

If you are seeing a login but it takes a long time for the password prompt to appear after logging in on a SCO box, see User login hangs for many seconds before password prompt comes up (SCO 5.0.5 and 5.0.6 )

Telnet and Kerberos

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.

Scripting telnet

Generally, you want "expect". See A Y2K Problem solved with Expect.

Some telnet clients (like Kermit) have innate scripting ability.

Here's an example of Kermit scripting:

set host <hostname> /telnet 
if fail (take-desired-action) 
input 10 login: 
if fail ...

See Running script with telnet?.

Does baud rate matter for ssh or telnet?

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.

Got something to add? Send me email.

1 comment

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Anthony Lawrence

Fri Sep 16 14:43:59 2005: 1094   BigDumbDinosaur

When testing mail, I'll often have a customer do something like "telnet mailserver 25" or "telnet mailserver 110".

You can also do something like "telnet mailserver smtp" or "telnet mailserver pop3". This, of course, assumes that your /etc/services file is present (it better be!) and accurate. In fact, you can telnet to any port you want -- try "telnet www". <Grin>

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us