Lab 27: Restricting Remote Access with ACLs
SSH everywhere means anyone on any subnet can attempt to log into your devices. Lock the VTY lines with an access-class ACL so only the management network may even try. Difficulty: Intermediate · Time: ~25 min.
Lab objectives
- Configure SSH access (from Lab 10)
- Write a standard ACL permitting only the management subnet
- Apply it to VTY lines with access-class
- Prove denied subnets can't even reach the login prompt
Topology & addressing
Router with SSH configured (192.168.1.1). Management PC on 192.168.1.0/24; "user" PC on 192.168.20.0/24 routed to the router. Both can ping it — but only one should manage it.
Step-by-step configuration
access-list 5 permit 192.168.1.0 0.0.0.255 | Only the management subnet |
line vty 0 4access-class 5 in | ACL applied to remote-login sessions specifically |
| Test SSH from both PCs | Management PC: login prompt. User PC: connection refused |
Verification
From 192.168.1.x: ssh -l admin 192.168.1.1 works normally. From 192.168.20.x: the connection is refused before any password prompt — the ACL blocks at the line level. show access-lists shows deny matches climbing with each attempt: your audit trail of who's knocking.
Next lab: labs hub · test yourself: CCNA practice test.
Frequently asked questions
What does access-class do differently from ip access-group?
access-class applies an ACL to the device's own VTY (remote-login) sessions; ip access-group filters transit traffic through an interface.
Why restrict VTY access when SSH already needs a password?
Defence in depth — attackers outside the management subnet can't even attempt password guessing, eliminating brute-force exposure from user networks.
Should the ACL be standard or extended for this?
Standard is typical — you're filtering purely by source; the destination (the device itself) is implicit in access-class.
Related articles
Want hands-on training?
Learn this on real Cisco lab devices with placement support at Attila Technologies, Ahmedabad.