Image of Jeremy L. Gaddis, CCNA, CCNP (and Cortney, in case you were wondering)

Setting Passwords on Cisco Devices

by Jeremy L. Gaddis on September 8, 2011 · 0 comments

Post image for Setting Passwords on Cisco Devices

Now that we’ve learned how to save our configurations, we need a way to keep outsiders from getting in and messing them up.

Passwords are our first line of defense in keeping unauthorized persons from gaining access to our routers and switches. There are four main types of passwords you’ll encounter while studying for the CCNA test:

  • console password – secures access via the console
  • enable password – secures access to privileged exec mode
  • enable secret password – same as enable password, but encrypted
  • VTY password – secures access via telnet and/or SSH

In this article, you’ll learn what they are and how to configure them.

Choosing Passwords

In our home Cisco labs and the articles on this site, we’ll often use simple, short passwords such as “cisco”. We do this only for convenience. These passwords can be guessed very easily by automated tools and should never be used in a production network.

In general, you should use passwords that are least eight characters in length (I prefer at least 16) and use a combination of uppercase, lowercase, and numbers. In addition, use different passwords for each router or switch, whenever you can.

Console Password

In a previous article, Introduction to Cisco Devices and Cisco IOS, I wrote:

It is important to note that, by default, there is no security with regard to the console port. If someone is able to establish a console connection to a router or switch, they have complete control of the device. For that reason, it is important that we both configure passwords and keep the devices physically secured, such as in a locked room.

Without a console password configured, if someone is able to physically connect to our router or switch they can make any changes to the configuration that they want. This, as you might guess, is a Bad Thing™.

We configure a console password by going into line configuration mode for the console, which you access from global configuration mode. If you’re not currently logged into the console, you should see a screen that looks like this:

Miami con0 is now available

Press RETURN to get started.

Let’s set the console password to “cisco”.

Miami> enable
Miami# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Miami(config)# line console 0
Miami(config-line)# password cisco

Simple enough, right? We need to issue one more command, login, to tell the router that we actually want to require users to login to access the console. Note that you must both enable login and set a password.

Miami(config-line)# login

Go ahead and save your configuration and then log out of the console.

Miami(config-line)# end
Miami# write memory
Building configuration...
[OK]
Miami# disable
Miami> exit

You should one again be looking at a screen that looks like this:

Miami con0 is now available

Press RETURN to get started.

Let’s try to access the console again and see what happens.

User Access Verification

Password:

Great, it’s working. Anyone attempting to access the console of our device will now be required to enter the password before they are able to gain access. Simply enter the password (which won’t be displayed as you type it, for security) and you’ll be logged in and placed into user exec mode:

User Access Verification

Password:
Miami>

Enable Password and Enable Secret

enable password and enable secret both serve the same purpose, controlling access to privileged exec mode, but there is one important difference between them: enable secret uses encryption.

NOTE: We’ll cover both since you need to understand them for the CCNA exam, but you always want to use enable secret instead of the older enable password whenever you can.

We set both the enable password and enable secret from global configuration mode. Let’s set the enable password to “ccna”:

Miami> en
Miami# conf t
Miami(config)# enable password ccna
Miami(config)#

Exit global config mode, save your changes, and then return to user exec mode:

Miami(config)# end
Miami# wr mem
Building configuration...
[OK]
Miami# disable
Miami>

To verify that our enable password is working, let’s try to return to privileged exec mode and see what happens.

Miami> enable
Password:

Looks like it’s working! Go ahead and enter the password and you’ll be rewarded with access to privileged exec mode:

Password:
Miami#

Note that the console password is different from the enable password and configured separately. If you completely exit out of the device, you’ll be prompted for the console password in order to access user exec mode and then prompted for the enable password when you attempt to access privileged exec mode:

Miami# disable
Miami> exit

Miami con0 is now available

Press RETURN to get started.

User Access Verification

Password:
Miami> enable
Password:
Miami#

Before talking about enable secret let’s take a look at the device’s configuration. If you issue the show running-configuration command (or sh run for short), you should see a line in the configuration that looks like this:

enable password ccna

Notice how the password is unencrypted. We’ll compare this to the enable secret in just a minute.

Before continuing, though, let’s go ahead and remove the enable password since we don’t want to use it when we can use enable secret instead:

Miami# configure terminal
Miami(config)# no enable password
Miami(config)#

The enable secret is configured exactly the same, the only different is the command. Let’s set it to “ccna”, exit global configuration mode, and save our changes:

Miami(config)# enable secret ccna
Miami(config)# end
Miami# wr
Building configuration...
[OK]
Miami#

Just like before, take a look at the running configuration (sh run) and find the enable secret. It should look something like this (although the encrypted part may very well be different):

enable secret 5 $1$X15V$GPeb1NkFo1vYsgMBUtnEt/

NOTE: The enable secret uses the MD5 message-digest algorithm to generate a 128-bit “hash”. Although, in theory, MD5 is a “one-way” hash (meaning that it is impossible to obtain the original password given that hash), attacks against the MD5 algorithm have been discovered and US-CERT has stated that MD5 “should be considered cryptographically broken and unsuitable for further use”. It’s likely that we’ll see Cisco switch to a new algorithm in future versions of IOS.

The key thing to remember, however, is that enable password does not encrypt the password while enable secret does. Even though weaknesses have been found in MD5, it is still much more secure than using plain-text.

VTY Passwords

Back in Introduction to Cisco Devices and Cisco IOS, I also wrote:

When connecting to a device using telnet or SSH, we are connecting to VTY lines.

Thus, as you might guess, VTY passwords are used to control access to our routers and switches when connecting using telnet or SSH. The VTY password is separate from the others that we have looked at and, in practice, should be set to a different password as well.

By default, most routers and switches running Cisco IOS support five VTY lines which are numbered from zero to four (0-4). This allows for up to five simultaneous connections to the device.

Note that, unlike the console, a password must be set for all VTY lines or they cannot be accessed. This is because IOS includes the login command on the VTY lines by default. If you look at the running configuration (sh run) you should see the following near the very bottom of the output:

Miami# sh run
...
line vty 0 4
 login
 transport input all
!
end

By default, then, if you do not set a VTY password, you cannot login to the device using telnet or SSH. Instead, you’ll get an error message when you try:

$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.

Password required, but none set
[Connection to 192.168.0.1 closed by foreign host]

I like to be 100 percent sure, though, so I always manually issue the login command as well. Let’s go ahead and do that and configure a VTY password (“letmein”). Note the warning that IOS gives us when we issue the login before setting a password.

Miami# conf t
Miami(config)# line vty 0 4
Miami(config-line)# login
% 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
Miami(config-line)# password letmein
Miami(config-line)# end
Miami# wr
Building configuration...
[OK]
Miami#

With a VTY password configured, we can now log in to our router via telnet:

$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.

User Access Verification

Password:
Miami>

There’s one other important thing I should mention while we’re talking about VTY passwords and logging in via telnet. Even if we have a VTY password configured and can log in using telnet, IOS will not grant access to privileged exec mode if no enable password or enable secret has been set.

To demonstrate, let’s first remove the enable secret:

Miami# conf t
Miami(config)# no enable secret
Miami(config)# end
Miami# wr
Building configuration...
[OK]
Miami#

Now if we login using telnet and attempt to access privileged exec mode, one of two things will happen, depending on the device and IOS version: either you’ll be still be prompted for a password (which will be impossible to successfully provide, since it doesn’t exist) or you’ll receive an error message.

On devices that prompt for a password, your session will go something like this:

$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.

User Access Verification

Password:
Miami> enable
Password:

Other times you’ll simply be presented with an error message:

Switch> enable
% No password set
Switch>

service password-encryption

By default, the console password, enable password, and VTY passwords are shown in plain-text when we view the running configuration and startup configuration. There’s a command that we can use that will encrypt these passwords, however: service password-encryption.

If you look at the running configuration, the passwords are clearly visible:

Miami# sh run
...
!
line con 0
 password cisco
 logging synchronous
 login
line aux 0
line vty 0 4
 password letmein
 login
 transport input all
!

Let’s go into global configuration mode and turn on service password-encryption:

Miami# conf t
Miami(config)# service password-encryption
Miami(config)# end
Miami#

If we look at our running configuration now, the passwords are not shown in plain-text:

Miami# sh run
...
!
line con 0
 password 7 060506324F41
 logging synchronous
 login
line aux 0
line vty 0 4
 password 7 011F0310560E0F01
 login
 transport input all
!

This is better than plain-text, but just barely. The “encryption” used for these passwords, referred to as type 7 encryption, uses a very weak, reversible algorithm. To see just how weak it is, enter the type 7 encrypted version of our VTY password (“011F0310560E0F01″) into the Type 7 Reverser on Jeremy Stretch’s Packet Life website. It will very quickly spit out the original plain-text password, “letmein”.

Cisco Type 7 Password Decryption

Decrypted VTY Password

Lab Exercises

Summary

As you can see, choosing and setting strong passwords is the first line of defense in keeping authorized users out of our routers and switches. It doesn’t have to be the only one, however. We’ll cover some others, including Login Banners and access control lists in future articles.

Image Source

Previous post:

Next post: