Skip to content
Study CCNP

5.1.a Lines and local user authentication

5 min read ENCOR 350-401 v1.2 Updated

Aligned to Cisco's 350-401 ENCOR v1.2 exam topics.

On this page

What this objective tests

The exam wants you to configure and verify secure management access on an IOS XE device. You must control three things: who can open a session, which protocol they use, and what privilege level they get. This matters because the line is the front door of the device. A strong routing design does not help if the VTY lines accept Telnet from any source.

Lines, users, and privilege levels

  • Console line (line con 0): physical or virtual console access.
  • VTY lines (line vty 0 15): remote CLI sessions. IOS XE has 16 VTY lines.
  • Local user: an entry in the device username database. Use login local on the line to use it.

Privilege levels decide what a user can do after login:

LevelMeaning
0Very limited. Few commands.
1User EXEC mode. The default.
15Privileged EXEC mode. Full access.

A user created with privilege 15 lands in privileged EXEC mode after login. No enable password is necessary for that user.

Always hash secrets. algorithm-type scrypt uses a strong one-way hash. The old password keyword and type 7 encoding are weak and reversible.

SSH prerequisites

SSH needs three things before it works:

  1. A hostname other than the default.
  2. A domain name from ip domain-name.
  3. An RSA key pair from crypto key generate rsa.

Then force version 2 with ip ssh version 2. Use transport input ssh on the VTY lines to block Telnet.

login local versus aaa new-model

MethodWhat it usesWhen to use it
login with passwordOne shared line passwordNever in production
login localThe local username databaseLabs and break-glass access
aaa new-modelAAA method lists, central servers firstProduction networks

Note: When you enable aaa new-model, the lines stop using login local. They use the default AAA method list. Plan for this before you type the command. See 5.1.b AAA authentication and authorization.

Example: secure VTY access on R1

Scenario: R1 has management IP 10.10.10.2. The management subnet is 10.10.10.0/24. Only SSH from that subnet is allowed. The admin user is netadmin at privilege 15.

hostname R1
ip domain-name ccnpstudy.local
crypto key generate rsa modulus 2048
ip ssh version 2

username netadmin privilege 15 algorithm-type scrypt secret <unique-local-secret>

ip access-list standard VTY-MGMT
 remark Management subnet only
 permit 10.10.10.0 0.0.0.255
 deny any log

line con 0
 login local
 exec-timeout 5 0
 logging synchronous

line vty 0 15
 transport input ssh
 login local
 access-class VTY-MGMT in
 exec-timeout 10 0
 logging synchronous

What each part does:

CommandPurpose
username ... algorithm-type scrypt secretCreates the local user with a strong hash
transport input sshPermits SSH only. Blocks Telnet
login localUses the local username database
access-class VTY-MGMT inPermits only 10.10.10.0/24 sources
exec-timeout 10 0Disconnects idle sessions after 10 minutes

Expected verification output:

R1# show running-config | section line
line con 0
 exec-timeout 5 0
 login local
 logging synchronous
line vty 0 4
 access-class VTY-MGMT in
 exec-timeout 10 0
 login local
 transport input ssh
 logging synchronous
line vty 5 15
 access-class VTY-MGMT in
 exec-timeout 10 0
 login local
 transport input ssh
 logging synchronous

Note: line vty 0 15 splits into two blocks in the running configuration. The commands apply to both blocks.

After netadmin connects from 10.10.10.50:

R1# show users
    Line       User       Host(s)              Idle       Location
*   0 con 0                idle                 00:00:00
  578 vty 0     netadmin   idle                 00:00:12 10.10.10.50

R1# show access-lists VTY-MGMT
Standard IP access list VTY-MGMT
    10 permit 10.10.10.0, wildcard bits 0.0.0.255 (3 matches)
    20 deny any log (1 match)

The permit counter increases on good connections. The deny counter increases on blocked sources. Both counters prove the control works.

Lab: lock down R1

Topology:

[Admin PC 10.10.10.50] ---- [R1 10.10.10.2]
[Other PC 10.99.99.50] ----/

Do these steps:

  1. Set the hostname to R1 and the domain to ccnpstudy.local.
  2. Generate a 2048-bit RSA key pair.
  3. Enable SSH version 2.
  4. Create user netadmin with privilege 15 and an scrypt secret.
  5. Create standard ACL VTY-MGMT that permits 10.10.10.0 0.0.0.255 and denies the rest with logging.
  6. Configure line vty 0 15 with transport input ssh, login local, access-class VTY-MGMT in, and exec-timeout 10 0.
  7. Configure line con 0 with login local and exec-timeout 5 0.
  8. Connect with SSH from 10.10.10.50 as netadmin.
  9. Try to connect from 10.99.99.50. Confirm the connection fails.
  10. Run show users and show access-lists VTY-MGMT. Confirm the counters match your tests.

Expected results:

  • The admin PC connects and lands in privileged EXEC mode.
  • The other PC is refused before authentication.
  • The ACL shows one permit match and one deny match.

Exam traps

  • login with a line password does not identify the admin. login local does.
  • transport input all permits Telnet. Use transport input ssh.
  • access-class goes under the line. It is not the same as ip access-group on an interface.
  • crypto key generate rsa fails without a hostname and a domain name.
  • exec-timeout 0 0 means sessions never time out. Do not use it in production.
  • line vty 0 4 covers only 5 lines. Attackers can use lines 5-15 if you leave them open. Configure line vty 0 15.

Pass check

You are ready for this objective when you can do these things:

  • Explain why SSH needs a hostname, a domain name, and an RSA key pair.
  • Write the four VTY commands for SSH-only local login from memory.
  • Explain the difference between privilege level 1 and privilege level 15 at login.
  • Read show users output and name the connected user and source IP.
  • Prove an access-class filter works by reading its match counters.

Related objectives