Before we start, I’ve kept VLAN10 at 10.1.1.2/24. The default gateway and setting and everything else is the same as previous section.
Telnet
Running on TCP port 23, Telnet is an excellent way to logically hop around a network rather than physically hopping around a network.
Even if all the devices you are working with are in one rack whether that be in a home lab or whether it be in a production network instead of continually moving your console cable around from one console port to another, you can just Telnet from one device to another.

If I’m connected to R1 right now, I can logically connect to the switch via Telnet as long as I keep a few simple rules in mind. So let’s bring the switch right back up because we need to talk about this VTY things there at the bottom of the config :

We’ve already worked with console port. We know what exec-timeout and logging synchronous are.
Here we have two groups of something called a “line vty” ! These are the virtual terminal lines that we use to connect to a device via Telnet. You’ll find more of them by default on a switch than you will on a router because your switches have 16 vty lines and your routers have 5, and I know it looks like this has 15 vty lines but notice it starts with 0 and if you count on your fingers, you’ll see that is indeed 16.
Why this logging are already there? That’s weird because we haven’t seen that before. We didn’t see them on the console line. We don’t see it there now. So why is this there by default? It sounds like we could Telnet to a Cisco device by default.
So let’s try it now:
Let’s go over router 1: >1
And then : ping 10.1.1.2

Everything seems ok.
So I’m going to do ‘ telnet 10.1.1.2’

We are rejected immediately!
It says : ‘trying 10.1.1.2 … open” So it means that the connection opened.
And then we have something called ‘password required but non set’ which is a pretty explicit security message for this day and age( It should say username and password for example)

While login is enabled on our Cisco switch by default ( and it would be on the router as well and you’ll see the word ‘log in’ under the vty line), a password is certainly not set because I think we can all agree that a default telnet password on a Cisco device would be a very bad idea. So we have to configure that and for that let’s hop over to the switch and configure the vty lines.
Notice how I do this. I’m going to do all the lines at one time, both groups. You don’t have to do ‘line vty0 4’ and then ‘line vty 5 15’ and you’re never going to put a password on each individual line. We’re putting a one size fits all password here and it’s pretty simple.
(here we choose the word ‘success’ as our password)

Now I’ll do a ‘save’ and go to R1, and now I’ll try telnet again.

Something a little different here! We’re prompted for a password (vty line requires one)
So I should enter ‘success’ now to continue.

I want to Telnet over that switch because I want to put some commands on it.
Notice where I am by default… user exec… we see the arrow head there. So I’m in user exec by default, and I call it “tourist mode”! because we can do a lot of looking around but we can’t touch anything! We can run a lot of show commands from a user exec but we can’t really do anything there.

So we need to get up into “enable mode”

It says ‘no password set’ !! It doesn’t make sense because we just set a password when we were on the switch.
Here’s the deal with telnet. You’ve already seen that vty lines require a password and the user is put into ‘user exec’ by default.
By default you’re put in a user exec. And by default, unless there is an enable password or an enable secret set on the device you’re telnetting to, you’re not going to be able to enter enable mode.

So the switch is telling you what the problem is, but you couldn’t do anything about it via telnet.
So let’s go ahead and set an enable password.
So we should exit out of here first.

Let’s go over to the switch and we’ll pretend we’re somebody else and put in ‘enable secret CCNA’

What password should I put in here? It’s always going to be vty line password here ( not console password and not the enable seeker or the enable password). We need to put in ‘success’

So we’re back to switch1. Now we’re at the enable prompt.
And now we want to go into enable mode and now this time we’re prompted for the password.
What do we put in here? If we had an enable password and an enable secret configured which one we put in?
Always put enable secret! It always takes precedence.

And you’re in, so now I have successfully committed Telnet. I have telnetted over to the switch, I authenticated on the vty lines and then I went into enable mode, and all is well.
So let’s go ahead and log out of there.
There are two things you always want to do when you’re leaving a client’s site. You’ve got to turn your debugs off, and you’ve always got to close any open telnet connection you have.
So always do an exit or a log out here to cancel out or just leave your telnet connection.
Let’s go over to the switch and have a look at the config at the very bottom here.

And we scroll to the bottom and you can see the last three lines show what you want to see.

There is a way to skip the enable password and there are two ways to do it.
You can do it on a per user basis which means we have to have a username password database or you can do a ‘one size fits all command’ here on the vty lines that will allow telnetted users to go straight to enable mode. They will not be prompted for the enable password. So this is good command to know.

‘privilege level 15’ assigns incoming telnet users the highest privilege level there is (level 15) and that is the privilege to be put straight into enable mode and do pretty much whatever you want if you don’t have them tied in some other way.

So let’s go back to R1 and telnet over now, and I’m going to be asked for the vty line password.

There is no prompt for the enable password. There is no prompt for enable secret. There is no prompt for anything. I was put straight into that config mode.
So let’s go ahead and log out of there and go back over the switch.
- Logout > 6
So now we’ve seen how to put a vty line password on. We know all the steps we are going to be hit when you log in. First off you’ve got to have the vty line password. You should be asked for an enable secret or enable password if you want to get into enable mode, or the admin can use privilege level 15 on that device’s vty lines. That puts everybody straight into enable mode. Maybe you don’t want that.
So I’m going to build a username password database like we did earlier and I’ll show you exactly how to handle that on the vty lines.

You notice two of the users have username password combinations and that’s it and that’s fine. But for myself I assigned myself privilege level 15.
So now I’m going to go to the vty lines and I’m going to take off the password ‘success’.
- Line vty 0 15 > no password success
And I’m going to take off the privilege level command. This is just good housekeeping. If you’re not using commands anymore, take them off.
And instead of login what do I need here? ‘login local’

So we’ll go over and do a couple of telnets, and check this out first:
- ^z > wr > 1 > telnet 10.1.1.2 > jim > mora >
- And there I’m in enable mode and I am indeed prompted for the password so that all worked out exactly like it should have.

Now I’ll try connecting as myself.
As you noticed, I was put straight into privilege level mode.

Telnet’s great for zipping around your internal network, but think about using it across a WAN. Telnet sends all data and passwords in clear text. Once the wrong person gets ahold of that info, they can come right in and take over your router.

So that password is going to go straight across, the data goes straight across, and someone who picks that off, says “ok I’ve got the data. But even more importantly I got the keys to the kingdom! I got the password!”
Just one port down at TCP port 22 is Secure Shell, a much more secure version of Telnet. SSH encrypts everything, data and passwords.
So why does anybody use Telnet? Why are we even talking about it when the password and the data and username and anything else is going to be hashed?
The obvious questions:
- Why don’t we use SSH for all remote connections?
- Why do we still use Telnet?
One of the usual answers for the first question is that SSH is more complex to configure that Telnet, to which I have two responses.
- We’re not scared of a more-complex configuration.
- It would be hard to be less complex that Telnet.

The only issue you bump into with SSH is that not every device supports it, but even that’s not much of an excuse these days. We do have to save SSH configs for another day, but for now, be aware of that one major difference between Telnet and SSH for your exam and especially for real-world networking.