CLI Passwords 1

By certskills September 9, 2015 12:05

Protecting access to the CLI of Cisco routers and switches starts with basic password security. From there, you can move on to use per-user login security that requires both a username and password, whether using locally-configured username/password pairs or whether taking advantage of the authentication servers already used by users inside the company. For the CCENT and CCNA R/S exams though, you start with simple passwords. This lab gives you some practice with how to configure basic passwords (with no usernames) to protect CLI access.


Configure switch SW1 with password security for console, telnet, and privileged-mode access. Configure the passwords so that all users use the same password to reach user mode from the console, with no per-user username required. Likewise, use one password for all users who Telnet into the switch to reach user mode.

This lab begins with all the interfaces shown in Figure 1 working, with IPv4 addresses configured, and with all hosts able to ping other local hosts and hosts in the rest of the Enterprise.

The specific rules for this lab are as follows:

  1. Use password “joy” to protect console access for all users to switch SW1.
  2. Use password “peace” to protect Telnet access for all users to switch SW1.
  3. Use password “kindness” to protect access to privileged mode for all users, using the more secure configuration option.


Figure 1: Network for this Lab, with Console Access Switch SW1


Initial Configuration

Example 1 shows the non-default configuration added to switch SW1 before your work for this lab begins. Basically, the switch has already been configured with an IP address and a default gateway to allow telnet access.

Example 1: SW1 Initial Configuration


It’s Now Time for Your Answer

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

Testing this lab (if you go to the effort to configure in an environment where you can test) is pretty easy. Simply connect to the console, and try to login with the configured password. Similarly, just Telnet into the switch, and try the Telnet password. From either, use the enable command to then test the enable password.


Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

When you have completed the lab, you can test your work. Open a new “Telnet to Console session” with the Switch and you should receive a login prompt asking for password. Then login using the Password you assigned for Console access. Next you can select another node from the topology and connect to that nodes console port, from there Telnet to the switches VLAN 1 IP address from that node and you should see the vty password prompt. Try using the Password you assigned for Telnet access to the switch.

Network Device Info:

This table lists the interfaces listed in the lab exercise documentation versus those used in the sample .VIRL file.

Device Lab Port  VIRL Port
SW1 G0/1 G0/1
SW1 F0/1 G0/2
SW1 F0/2 G0/3

Host device info:

This table lists host information pre-configured in VIRL, information that might not be required by the lab but may be useful to you.

Device IP Address Mac Address User/password
PC 02:00:11:11:11:11 cisco/cisco
S 02:00:22:22:22:22 cisco/cisco

Handy Host Commands:

To see PC IP address: ifconfig eth1

Ping example: ping -c 4

Trace example: tracepath

To connect to another node via telnet: telnet




Serial Config 1
Answers: Serial Config 1
By certskills September 9, 2015 12:05
Write a comment


  1. Jonathan July 29, 11:11


    I know this is lab is 3 years old but I am now going through my CCENT studies with your book that I bought 5 months ago. So I am working with what I got. 🙂

    That said I noticed in your SW1 initial config, the “no shut” command was not included so the SVI would still be listed as down and therefore telnet wouldn’t work. I copied this from the show run command from my 3750 switch. This was right after I did a delete vlan.dat, erase nvram:, and then reload.

    interface Vlan1
    no ip address

    I checked the answer to see if the no shut was in there and it wasn’t. I understand the stem of the question was to see if I knew how to configure passwords, but even if I did I wouldn’t be able to test on real gear because the SVI would administratively down.

    Kind regards

    Reply to this comment
    • CCENTSkills August 3, 16:14

      Hi Jonathan,
      I agree, the SVI needs to be administratively up, regardless.

      There are probably about three or four perspectives as to why I think the lab is fine as is though in light of that fact, but I don’t think they’re constructive or instructive at all, so I won’t bore you. Just as one example, a “show run” in a pod that shows the absence of “shutdown” (as is the case in this lab) means that at that switch, at it’s beginning point for the lab, the SVI is enabled, and therefore the solution does not need a “no shut”. But I’d say treat the exercises as a structure to explore, and to understand the important part – in this case, that the SVI has to be no shut to be functional.
      Thanks for the heads up,

      Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.