Wednesday, May 07, 2014

CCNA / CCENT / CCNP In-Depth Lab:

A Guide To The Password Command (And Pals)

Thanks for all your shares and Google +1s for this new series!  : )   

One of the first commands you're introduced to during your CCNA and CCENT studies is the password command, and while that command itself is pretty darn straightforward...

R1(config)#line vty 0 4
R1(config-line)#password ?
  0     Specifies an UNENCRYPTED password will follow
  7     Specifies a HIDDEN password will follow

  LINE  The UNENCRYPTED (cleartext) line password

... knowing where to config it in your Cisco router config is a pretty big deal, as are a couple of related commands.

In this case, we're putting the password command on the VTY lines (or "vty lines" if you prefer -- no requirement to put it in caps).   That means we're protecting our Telnet or SSH lines, and in this lab we'll work strictly with Telnet.

You've probably worked with software that had a default password like "admin".   Not only does a Cisco router not have a ridiculously easy-to-guess default password, there is no default password!    (I'm sure we can agree that it would be a bad thing for Cisco routers to have default passwords for remote access.)

Here's what our VTY line config looks like by default:

line vty 0 4
< nothing here, including this line : )   >

Literally, there's nothing to see here, but don't move along -- we're about to put something there.

Let's see what the result is when we attempt to Telnet to a router that hasn't been configured for remote access. 

CCNA CCNP Telnet Lab

From R1, we can ping with no problem...


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:

Success rate is 100 percent (5/5), round-trip min/avg/max = 68/68/68 ms

... but we can't telnet to

Trying ... Open

Password required, but none set

[Connection to closed by foreign host]

At first glance, that seems pretty odd, but the router is telling us exactly what the situation is.  We need a password, but none has been configured.   Let's take care of that with the login and password commands on R2's VTY lines.

R2(config)#line vty 0 4
% Login disabled on line 2, until 'password' is set
% Login disabled on line 3, until 'password' is set
% Login disabled on line 4, until 'password' is set
% Login disabled on line 5, until 'password' is set
% Login disabled on line 6, until 'password' is set

R2(config-line)#password CCNA

True confession time: This output scared the crap out of me the first time I saw it, and from the emails I've gotten over the years, I know I'm not the only one who had that reaction.  It's easy to look at the first part of that output and see "Login Disabled" and start to panic, but read the rest -- it's only disabled until the password is set.

Moral of the story:  It doesn't matter whether you put the login or password commands on the VTY lines first, just that you put them both in.  (If you enter password first, you will not receive any messages regarding the login command.)

We'll continue our CCNA / CCNP Command Reference right after this quick message.   Be sure to click these babies when you're done (right now is good, too!)

Don't wish or hope for CCNA exam success.

Create your success with my CCNA Success! Study Guides!

Working on the single CCNA exam?  Grab the ICND1 and ICND2 guides, and read them with any of the free Amazon Kindle Apps -- you do NOT need a Kindle to read these!

(Their cloud reader is great!)

I personally guarantee you'll be glad you did. - Chris B.

Get 150 Extra Subnetting Practice Questions For Just $4.99!

Thanks for your purchases -- all of us here at TBA appreciate them!  

Now that we have the login and password commands on R2, let's give that R1-to-R2 telnet attempt another shot.

Trying ... Open

User Access Verification



Looks good! 

A couple of important points about that telnet attempt....

1.   The password never appeared on the screen.  Where some applications will display an asterisk for each character entered on the screen, a Cisco router will not do that.  You won't even see the cursor move.

2.   Note that "Password:" appeared twice.  That's a tipoff that I mistyped the password the first time around, and by "mistype", I mean that I entered "ccna" instead of "CCNA".  This password is case-sensitive.

3.   Note the R2 prompt.  By default, an incoming telnet user is placed into user exec mode.

Since you can't do much in user exec mode, let's go into privileged exec mode and start configuring R2 remotely.


% No password set

Whoops!  D'oh!  Dangnabbit!

(Use the exclamation of your choice in this situation.)

The enable secret and enable passwords are another important part of your CCNA study and a vital part of your Telnet configuration.   By default, there must be an enable secret or enable password set on the router you're telnetting to, or you're stuck in user exec mode.

There's a bit of a Catch-22 here in that we need to configure the enable password on R2, but we can't do so without already having the enable password on R2.  Therefore, someone physically present at R2 is going to have to configure that enable password before we can continue.

Luckily for us, I just happen to be at R2, so let me create that password...

R2(config)#enable password CCNP

... and having logged out of the earlier telnet connection, let's give that R1-to-R2 connection another try.

Trying ... Open

User Access Verification



Success!   And for success on your CCNA and CCNP exams, we better be clear on the following points from that config:

1.  We're prompted for a password immediately, and that's the VTY line password "CCNA".

2.  As before, we're placed into user exec mode, and then try to enter enable mode.

3.  Since there is an enable password, we're prompted for that, and I entered "CCNP".  Again, nothing appeared on the screen when I entered the enable password.

4.  After successfully authenticating with the enable password, we're in enable mode!

Let me introduce you to Chris Bryant's First Law Of Networking:

Almost every solution introduces a potential issue.

(If you use that you owe me royalties.)

We've gone over some really important points regarding passwords and Telnet in this lab, but there's one great big issue with this particular setup.   We'll continue the lab right after this quick message -- join us in "Certification With A Cause!"

We're contributing 20 meals to the Central Virginia Food Bank for every paid signup in May to any single-exam course, and a whopping 100 meals for every CCNP All-In-One Video Boot Camp.

Ignore the prices you see below -- every single one of my single-exam courses is just $44 when you use these links, and my CCNP All-In-One course is only $99.

The time to create your future is now, and that includes earning these important certifications.   Click these links and let's get to it!

Chris B.

Thanks for supporting "Certification With A Cause!"

CCNA Video Boot Camp -- Just $44 With This Link!

CCNA Security Video Boot Camp -- $44 With This Link!

All 3 CCNP courses for just $99, and we donate 100 meals to

the Central Virginia FoodBank!

From all of us at TBA and everyone at the Central Virginia Food Bank -- thank you!

Now back to our lab!

Right now, we have Telnet connectivity.  That's great.  

But who is "we"?

"We" is anyone who happens to know (or guess) that particular password.    Anyone.   

That includes former admins on this network, and one of them just might be tempted one day to see if the password they used when they worked there will still work today.

That includes someone who was looking over your shoulder and directly at the Cisco router config in front of both of you, and who noticed what your Telnet password is (and that it wasn't encrypted, so it was easy to read).

What we have right now is what I call a "one-size-fits-all" password.   Anyone who knows it can get in, and there's not even a prompt for a username.  

This is why we'll often create a username / password database on our router.   Each user will have their own individual password, and they have to use that specific password.   If they try to log in with their own name and someone else's password, they can't get in.

Let's see this in action with two users, Randy and Lanny Poffo. Randy's username is RPOFFO with a password of MEMPHIS; Lanny's username is LPOFFO with a password of GENIUS.

The first step is to get over any intimidation you may have about creating a database.  This is the easiest database you're ever going to build, and we do it with the username command.

CCNA Lab: Username / Password Command

Take a deep breath; we don't have to know all of those commands for the CCENT, CCNA, and CCNP commands.  Frankly, you could go through a great part of your career and only use one or two of them.   We'll look at those particular options in a future lab.   

The key is that just about everything there is an option.   The only required values are the username and password values.  No need for database anxiety here!

Note the "privilege" option.  Just as before, by default, each user will be placed into user exec mode upon authentication.

Let's say we want Randy to be placed into privileged exec after he authenticates successfully.  To make this happen, we'll put privilege 15 in the middle of his username / password entry.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#username RPOFFO privilege 15 password MEMPHIS

R1(config)#username LPOFFO password GENIUS

Note the differing output in the config.  (The zero in each output refers to the encryption level.  In this case, there isn't any encryption, hence the zero!)

username RPOFFO privilege 15 password 0 MEMPHIS

username LPOFFO password 0 GENIUS

There's just one more little thing we need to do, and it's really easy to overlook.   So let's not overlook it, and instead use IOS Help to have a look at our options for the login command on the VTY lines.

line vty 0 4
 password CCNA

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#line vty 0 4
R1(config-line)#login ?
  local   Local password checking
  tacacs  Use tacacs server for password checking


Note the options local and tacacs.   You may not have run into tacacs (or tacacs+) at this point in your studies, so for now I'll just mention that this option would allow us to host our password database on separate hardware.

The option we're most interested in now is local.  "local password checking" refers to the use of a username / password database for VTY line authentication, rather than the one-size-fits-all password we placed directly on the VTY lines earlier in this lab.

We already have that database, so let's remove the login command and put login local in its place.  

R1(config-line)#no login
R1(config-line)#login local

Note that I didn't remove the one-size-fits-all password CCNA. In the real world, I would do that for housekeeping, but here I've left it to illustrate that this password is no longer good for entry.

Let's have Randy log in first.

Trying ... Open

User Access Verification

Username: RPOFFO


He goes straight into privileged exec mode.   How about Lanny?

Trying ... Open

User Access Verification

Username: LPOFFO

He's put into user exec, the default for incoming Telnetters.

Thanks for reading today's Command Reference!  Here are some bonus videos from my YouTube channel that deal with Telnet.  Dig in, and I'll see you Wednesday with more!

Chris B.

No comments:

Blog Archive