There are all kinds of tools for launching and managing Telnet sessions,
but deep down they're all pretty much the same things.
So when a session doesn't work out,
and that usually involves being unable to connect the way you'd expect,
no matter what operating system or hardware you're using,
you're probably seen symptoms of the same kinds of issues.
As we saw with SSH,
the first steps in diagnosing a login problem is to run through your
normal network connectivity and timeout checklist.
So for instance,
if you get a Telnet Unable to connect to remote host connection refused error,
run a tool Nmap against your server to confirm that Telnet is listening,
and listening on the port you expect.
In this case, the server is listening on Port 23, the default Telnet port.
Naturally,
if the Telnet software running on your host is listening on some other port,
then you want to specify the correct port when you launch your session.
Many systems had GUI interfaces that allow you to
configure a port a host will use.
On Linux systems,
you can control the port from the command line through the etc/services file,
which is just a plain text file containing the names of
well-known services and the port you want them to use.
I could edit the 23 of Telnet to read, say, 2323.
Now the inetd super daemon or another systems xind or systemctl,
read the services file and through the etc/inetd.
conf configuration file, apply its values to any Telnet sessions you launch.
Distributions that don't use inetd might hide their Telnet
configuration files in other strange places,
like etc/xinetd.
d/telnet, or in a hidden file called.
telnetrc in the user's home directory.
At least some recent versions of Windows will provide
configuration parameters in the registry under
HKEY_LOCAL_MACHINE\Software\Microsoft\TelnetServer,
and from within PowerShell, through the Telnet Admin command.
I think this is the kind of confusing variety that you can
expect might come with software protocols that have been
around nearly half a century.
I'm not sure you have to absolutely do this,
but I'll reboot the host to make sure the change is noticed,
and then try Telneting in through the default port.
It's a glorious failure.
Now we'll try once again using 2323, and we're in.
If your login attempt is rejected by the host,
it could be that you're simply not authorized.
Remember, Telnet doesn't concern itself with authentication,
and leaves that to the host operating system.
If you don't have whatever login right a host requires, you won't be allowed in.
If you run a busy Telnet server and find yourself facing No more
connections are allowed to Telnet server error messages,
I could be that you're received the maximum limit of concurrent connections.
Depending on your particular situation,
you should make sure that your host isn't configured with a
session limit that's too low for your needs.
On some systems, that setting will be found in the etc/xinetd.
conf file in the line reading instances equals.
You can change its value to instances = unlimited or to
any number you judge is appropriate.
When running Telnet from the command line,
you obviously need to follow each command with a carriage return.
For those of you who are too young to have ever seen a typewriter,
that's the enter key.
It makes some sense then that when you're scripting Telnet operations,
you might need to manually terminate a command with
a carriage return using \r\n.
Now if you've really been paying attention to these videos,
you might remember that I didn't include \r\n in the
bash script I created earlier, and yet it still worked.
Not all scripting environments are created equal,
and some will require different syntax in different context.
You might sometimes find that the contents of your Telnet session
aren't being displayed correctly in your terminal.
While it's not a problem here, if you do have trouble,
it can often be corrected by adjusting the size setting of your terminal client.
Going with 80 columns and 25 or so rows will usually work.
Well let's review what we've learned.
You can run Telnet directly from the command line through the Telnet shell,
or through a GUI interface.
Option requests can add functionality to Telnet sessions
beyond the standard network virtual terminals.
Option requests can be negotiated using the WILL,
WON'T, DO, and DON'T option codes.
You can escape a Telnet session into a shell where you can send commands,
using CTRL and right bracket.
Environ commands will display and edit environment variables,
and send commands will issue arguments.
You can also automate Telnet sessions through scripts.
On a Linux machine you can control the port a Telnet host
listens on through the etc/services file and through the Telnet
Admin command within Windows Powershell.
Finally, on some Linux systems at least,
you can edit the maximum allowed concurrent Telnet sessions from the etc/xinetd. conf file.