Lesson 2 — Device Access and Management-Plane Hardening

Week 7Lesson 2Required25 min estimated0% progress

Device Access and Management-Plane Hardening

Secure how administrators reach a Cisco device — enable SSH and disable Telnet, require local-username authentication, and apply the core password and banner hardening — then verify with show ip ssh and show users.

What you'll learn (5 objectives)~25 min: video → lesson → check → apply → lab prep

Learning objectives

Explain the management plane and why hardening device access is a first-day task
Configure SSH version 2 and force encrypted access with transport input ssh
Require local username authentication with secret hashing and login local
Apply password-policy hardening — enable secret, service password-encryption, exec-timeout, and a login banner
Describe AAA and when RADIUS or TACACS+ replaces local users, always with a local fallback

Terms you will see

Management planeenable secretservice password-encryptionexec-timeoutlogin localtransport input sshcrypto key generate rsaAAARADIUSTACACS+

Time breakdown

Read the notes12 min
Walk the SSH configuration8 min
Predict the Telnet-still-open case5 min

Opens on YouTube

Free CCNA | SSH | Day 42 | CCNA 200-301 Complete Course

By Jeremy's IT Lab · Opens externally on YouTube

Assigned watch: ~6 min

Where to stop

Skip the intro if you already know why Telnet is unsafe; the configuration sequence is the core.

The source marks this segment timestampStatus="unresolved" with no start or end, so no bounds are shown here.

Watch on YouTube

The link opens in a new browser tab. Return here when you finish watching.

Watch for these concepts

The full SSH prerequisite chain, in order
Why each step is mandatory rather than merely recommended

Go beyond the video

The assigned video introduces the idea. CCNA Practice Labs completes the learning path: clarify core concepts, explore how each device behaves, visualize the communication path, check your understanding, and prepare for hands-on lab work.

Watch the concept → understand it → visualize it → practice it → apply it.

The plane you are protecting, and the three password doors

A Cisco router or switch ships from the factory with no security at all — plug in a console cable and you are in privileged mode with no password. A device's work splits into planes: the data plane forwards user traffic and is filtered by the ACLs from Lesson 1, the control plane runs routing and STP, and the management plane carries how you administer the box. Hardening the management plane means encrypting the sessions, proving identity, and shrinking the attack surface.

Three independent password controls, three different doors

Control	Where	Protects
line console 0 password	Physical console port	Local cable access
line vty 0 15 with login local	Remote SSH/Telnet sessions	Network access to the CLI
enable secret	Global	Escalation from user-exec to privileged-exec

enable secret, and what service password-encryption is not

Use enable secret, never enable password: the secret is hashed in the configuration while the password is stored in clear text, and when both exist the secret wins. Line passwords still display in clear text, so add service password-encryption — but be clear about its limit. It is a trivially reversible obfuscation, not cryptography; anyone with the config can recover the original. The genuinely strong pattern is local usernames with secret, which is hashed, and which is also what SSH requires. Round it out with an exec-timeout so idle sessions close (the default is 10 minutes) and a login banner carrying an authorised-access-only warning.

SSH replaces Telnet, and AAA replaces local users

Telnet sends everything in plaintext, including your password, so anyone capturing packets along the path reads your credentials. SSH encrypts the whole session. The exam recommendation is blunt: disable Telnet, enable SSH version 2 only. On the VTY lines, transport input ssh is what actually refuses Telnet; transport input none refuses all remote CLI.

Local usernames work for a handful of devices but do not scale — adding an admin means touching every box. AAA centralises this against an external server.

The three A's

A	Question it answers	Example
Authentication	Who are you?	Username and password check
Authorization	What may you do?	Per-command permission (TACACS+)
Accounting	What did you do?	An audit log of commands run

RADIUS versus TACACS+

Protocol	Origin	Structure	Typically used for
RADIUS	Open standard	Combines authentication and authorization	End-user network access
TACACS+	Cisco	Separates all three functions; can authorize per command	Administrator access to Cisco devices

Always keep a local fallback

AAA moves the source of truth off the device. If your login method is "ask the TACACS+ server" and that server — or the path to it — goes down, every login attempt fails, including yours, at exactly the moment you need to fix the outage. Writing aaa authentication login default group tacacs+ local lists local as the second method, so the device falls back to its own username database when the server is unreachable and a break-glass account still works. This is the most common AAA lockout trap both on the exam and in production.

Enable SSH v2, require local login, disable Telnet

The full sequence, in dependency order

! Prerequisites for the RSA key: a hostname and a domain name
R1(config)# hostname R1
R1(config)# ip domain-name example.com
!
! Generate the key pair SSH uses to encrypt the session
R1(config)# crypto key generate rsa modulus 2048
!
! A local user with a HASHED secret — SSH cannot use a line password
R1(config)# username admin secret S3cure-Pass!
R1(config)# enable secret Priv-Pass!
R1(config)# service password-encryption
!
! On the VTY lines: authenticate against local users, allow SSH only
R1(config)# line vty 0 15
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 5 0
R1(config-line)# exit
!
R1(config)# ip ssh version 2
R1(config)# banner login ^C Authorized access only. ^C

Verify

R1# show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3

hostname plus ip domain-name give the RSA key a fully qualified name to bind to, which is exactly why crypto key generate rsa fails without them.
username admin secret creates the hashed local credential SSH authenticates against; login local tells the VTY lines to use that database instead of a shared line password.
transport input ssh is the switch that blocks Telnet. Omit it and Telnet stays open even after everything else is configured correctly.
ip ssh version 2 forces the stronger protocol version.
show ip ssh confirms SSH is enabled at version 2.0; show users then shows who is connected and over which line, so you can spot a session that arrived on the wrong transport.

Troubleshooting — SSH refuses the connection

Symptom: you set transport input ssh and a VTY line password, then try to SSH in, and the connection is refused. Diagnosis: SSH will not run on a line password. It needs a local username with a secret, a hostname and a domain name, and a generated RSA key pair — the pieces that let it authenticate a user and encrypt the session. Setting transport input ssh only says "no Telnet here"; it supplies none of the prerequisites. Fix: work the dependency order above, then confirm with show ip ssh. If the key generation itself fails, the missing piece is almost always ip domain-name.

What you should retain

Harden the management plane first — a factory device has no password at all.
SSH v2 prerequisites: hostname, ip domain-name, crypto key generate rsa, username with secret, login local, transport input ssh.
transport input ssh is what disables Telnet. Enabling SSH does not.
enable secret (hashed) over enable password; service password-encryption only obfuscates and is reversible.
AAA is authentication, authorization, accounting. RADIUS for end users, TACACS+ for admins — always keep a local fallback.
Verify with show ip ssh and show users.
Restrict which addresses may even attempt a session with access-class on the VTY lines.

Pause and predictNot scored — nothing is recorded

Before you read on

An admin runs every hardening command above except transport input ssh, leaving the VTY default. SSH now works and logins succeed against the local username. Is the device secure? What can still happen?

Interactive tool

See it happen

Optional~8 min

Flashcards

Drill the SSH prerequisite chain until you can recite the six steps in dependency order, and the RADIUS-versus-TACACS+ split until you no longer have to reason it out.

Open the tool

Section quiz

Check this section before moving on

Required8 questions~10 min

ACLs & Device Hardening

The quiz opens on its own page so you can focus on it. It is a Week 1 milestone, tracked separately from this lesson's own completion.

Topics covered

• Standard versus extended, and placement
• Wildcard masks and the host/any shorthands
• First match wins and the implicit deny
• The SSH prerequisite chain
• Password hardening and AAA fallback

Start the quiz

Study deeper

Topic guides extend this lesson — they do not replace the first-party walkthrough above.

Device Security

For the password-level reference, exec-timeout detail, and fuller AAA and centralized-authentication coverage

Open guide

Lesson orientation