Config Lab: Login Security 1

Wendell Odom
By Wendell Odom August 27, 2021 17:05

One of the first configuration items that become second nature is the configuration of basic password settings. But it is also easy to forget about the small differences in password security configuration once you get used to configuring your own lab the same way every time. This lab can give you some quick exercises on a few of those options.

All about Config Labs

The blog has a series of lab exercises called “Config Labs.” Each lab presents a topology with the relevant initial configuration for each device. The lab also lists new requirements, after which you should create the additional configuration to meet those requirements. You can do the lab on paper, in a text editor, or use software tools like Cisco Packet Tracer or Cisco Modeling Labs.

Once you have created your answer, you can click various tabs at the bottom of this post to see the lab answers, comments about the lab, and other helpful information.

The Lab Exercise


Configure console, Telnet, and enable mode security on all four devices in the figure as follows:

  • Protect console access for all device consoles with a password of ‘certskills’.
  • Protect privileged mode for all devices using password “ccnaskills” while storing the password as an MD5 hash.
  • Protect Telnet access by requiring a username/password combination to login. To that end, create a username ‘person’ with a password of ‘access’ using the most secure option to configure the user.
  • Assume all device interfaces shown in the lab are up, working, and correctly configured with IP addresses.
  • Assume routing is configured and working correctly.


Figure 1: Network Topology and Addresses



Initial Configuration

Examples 1, 2, 3, and 4 show the beginning configuration state of R1, R2, SW1, and SW2.

Example 1: R1 Config


Example 2: R2 Config


Example 3: SW1 Config


Example 4: SW2 Config

Answer Options - Click Tabs to Reveal

You can learn a lot and strengthen real learning of the topics by creating the configuration – even without a router or switch CLI. In fact, these labs were originally built to be used solely as a paper exercise!

To answer, just think about the lab. Refer to your primary learning material for CCNA, your notes, and create the configuration on paper or in a text editor. Then check your answer versus the answer post, which is linked at the bottom of the lab, just above the comments section.

You can also implement the lab using the Cisco Packet Tracer network simulator. With this option, you use Cisco’s free Packet Tracer simulator. You open a file that begins with the initial configuration already loaded. Then you implement your configuration and test to determine if it met the requirements of the lab.

(Use this link for more information about Cisco Packet Tracer.)

Use this workflow to do the labs in Cisco Packet Tracer:

  1. Download the .pkt file linked below.
  2. Open the .pkt file, creating a working lab with the same topology and interfaces as the lab exercise.
  3. Add your planned configuration to the lab.
  4. Test the configuration using some of the suggestions below.

Download this lab’s Packet Tracer File

You can also implement the lab using Cisco Modeling Labs – Personal (CML-P). CML-P (or simply CML) replaced Cisco Virtual Internet Routing Lab (VIRL) software in 2020, in effect serving as VIRL Version 2.

If you prefer to use CML, use a similar workflow as you would use if using Cisco Packet Tracer, as follows:

  1. Download the CML file (filetype .yaml) linked below.
  2. Import the lab’s CML file into CML and then start the lab.
  3. Compare the lab topology and interface IDs to this lab, as they may differ (more detail below).
  4. Add your planned configuration to the lab.
  5. Test the configuration using some of the suggestions below.

Download this lab’s CML file!


Network Device Info:

All interfaces in the topology match the lab figure.

Lab Answers Below: Spoiler Alert

Lab Answers: Configuration (Click Tab to Reveal)


Figure 1: Network Topology and Addresses


Example 1: R1 Config


Example 2: R2 Config


Example 3: SW1 Config


Example 4: SW2 Config

Commentary, Issues, and Verification Tips (Click Tabs to Reveal)


One of the first tasks to complete when configuring a new Cisco router or switch is configuring management access. This task includes the settings that define access to the console port and defining remote access privileges into a device. Sometimes people assume this task has already been completed correctly, leaving a poor device security configuration, leaving the device open to exploitation.

The first configuration requirement asked you to secure the console with a shared password of “certskills”. The command used to configure the password on a line is the password password command, and the command to enable login using that shared password is the login subcommand on that same line. These commands should have been configured on the console of each of the devices shown in the figure. (In fact, the same security configuration should be applied to all four devices based on the requirements in this lab.)

The second configuration requirement asked you to protect privileged mode with a shared password, which means you need to configure an enable password. The enable password password command would store the password in the configuration as clear text. If the service password-encryption global command was configured, IOS would store that password as an encrypted value. Unfortunately, that encryption is easily broken.

To meet the requirements of the lab, you have to use the enable secret password command. This command supports several methods to protect the password by storing only a hash or digest of the password. By default, with no other parameters, the enable secret command stores the password using MD5. So, the enable secret ccnaskills command meets all the requirements.

The third configuration requirement asked you to protect Telnet access with a per-user username/password, specifically for only one user to begin: user ‘person’ using the password of ‘access’. The lab asks you to use the most secure method, so as with the enable password, the most secure method uses the secret parameter instead of the password parameter.

Finally, to enable support for Telnet only and to use local usernames for those Telnet users, you need a couple of other commands. First, to enable Telnet only, use the transport input telnet command on the vty lines. (Some IOS versions and devices may default to support Telnet already.) Then to tell IOS to use local usernames for Telnet users, under those same vty lines, use the login local command, which enables a device to use the local username database for access.

Note that if you are doing this lab on real gear or even on CML, your device may support by default more than the 5 vty lines 0 through 4. Some support 0 through 15 by default. The point here is to make sure and configure the correct security commands, and to support Telnet or SSH, add those commands to all the vty lines supported on each device.

Known Issues in this Lab

This section of each Config Lab Answers post hopes to help with those issues by listing any known issues with Packet Tracer related to this lab. In this case, the issues are:

# Summary Detail
1 None No known issues related to this lab.


Why Would Cisco Packet Tracer Have Issues?

(Note: The below text is the same in every Config Lab.)

Cisco Packet Tracer (CPT) simulates Cisco routers and switches. However, CPT does not run the same software that runs in real Cisco routers and switches. Instead, developers wrote CPT to predict the output a real router or switch would display given the same topology and configuration – but without performing all the same tasks, an actual device has to do. On a positive note, CPT requires far less CPU and RAM than a lab full of devices so that you can run CPT on your computer as an app. In addition, simulators like CPT help you learn about the Cisco router/switch user interface – the Command Line Interface (CLI) – without having to own real devices.

CPT can have issues compared to real devices because CPT does not run the same software as Cisco devices. CPT does not support all commands or parameters of a command. CPT may supply output from a command that differs in some ways from what an actual device would give. Those differences can be a problem for anyone learning networking technology because you may not have experience with that technology on real gear – so you may not notice the differences. So this section lists differences and issues that we have seen when using CPT to do this lab.

Beyond comparing your answers to this lab’s Answers post, you can test in Cisco Packet Tracer (CPT) or Cisco Modeling Labs (CML). In fact, you can and should explore the lab once configured. For this lab, once you have completed the configuration, try these verification steps. 

  1. Connect to the console, and try to login with the configured password.
  2. Using the PC connected to a LAN interface, Telnet into the switch, and try the Telnet password.
  3. From either, use the enable command to then test the enable password.

More Labs with Related Content!

Config Lab: Switch IP 1
Config Lab: CLI Miscellany 1
Wendell Odom
By Wendell Odom August 27, 2021 17:05
Write a comment


  1. brahooke May 26, 20:14

    Why are some of the labs locked so you can’t access the CLI? I get an error popup saying “all usable tabs are hidden or locked away by design in this power state” Is this by design and part of the challenge of the lab? Please explain.

    Reply to this comment
    • certskills June 16, 17:02

      I’m not sure what you mean, as I get no such error when opening this or any other lab. The error is not intentional. Certainly, it’s not a message generated by design by me for this lab. Sorry I can’t be of more help.

      Reply to this comment
      • brahooke June 16, 20:52

        That was my mistake Wendell. It seems there was a PT setting under Options>Preferences>Show/Hide tab that allows you to access CLI options for the devices on the topology. My apologies, even though I have completed “Introduction to Packet Tracer” my usage of the application is no where near where I need it to be.

        Reply to this comment
  2. Niels July 15, 02:06

    Hi there,

    The latest packet tracer does not support the files for this lab. Which version should I use?

    Kind regards,

    Reply to this comment
    • certskills July 15, 09:57

      Could you tell me what version you’re using and what error message you see? Reason I ask is that with PT, newer versions of code should open older files, at least for several versions. Also, I can open the .pkt file as downloaded from this post with PT 8.0 and 8.1. However, you’re the second recent person to make a similar comment, so I’m wondering if something unusual is going on.
      In short, I can’t recreate your problem.

      Reply to this comment
  3. jorge3687 October 16, 20:44

    Hello, in this lab you ask for a username/password combination to login to telnet, yet in the answers you dont configure the username

    Reply to this comment
    • certskills October 31, 10:49

      Hi Jorge,
      Uhh, I think it’s the first line in the config section for each device in the sample config. “username person secret access”. Or am I missing your point? Let me know if so.

      Reply to this comment
  4. GJM November 8, 22:50

    Hi I got all of the configation correct except for the ‘transport input telnet’ command. I am not sure where I am missing that requirement from the scenario explained. Can you please explain where that is implied it is required in the configuration?

    Reply to this comment
    • Wendell Odom Author November 11, 18:01

      Hi Gabriel? From errata processing? Regardless…
      I probably imagined a requirement of “Telnet should work” without stating it. That transport input command is required for Telnet to work on a real router, for most of the history of IOS, due to the default setting of “transport input none”, which would prevent incoming Telnet or SSH. But looking back at the lab, it doesn’t say “make Telnet work”. So literally, it’s not required, but probably useful to think about for learning.

      In fact, for all these, it’s a chance to learn more commands and be better prepared.

      Reply to this comment
  5. Charlie November 25, 14:02

    Hello Grendal,

    I hope all is well.

    Please note, ‘Configure console, Telnet, and enable mode security on all four devices in the figure as follows…

    Yet in the ‘Lab Answers Below: Spoiler Alert’. You only mentioned to configure the username on sw1 and sw2.

    Should the username and password be configured on all devices


    Reply to this comment
  6. Bernard May 20, 01:54

    I have started working on each of your labs and I am getting used to it. Its great to be able to configure all of the devices and satisfying when I see that I did the same way as in your spoilers. I even checked it using show running-config and used telnet command to remotely connect to the other devices from the local unit you are currently in.
    Your study plan in your book is an effective learning for me.
    Thanks a lot Wendell!

    Reply to this comment
    • Wendell Odom Author May 23, 13:42

      Wonderful! Glad it’s a help. Also, your future comments here should appear immediately now that I’ve approved your first comment – FYI.

      Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email