VTY Line Security
Lab Objectives
- Secure the router's VTY (virtual terminal) lines so only SSH from the management subnet (192.168.3.0/24) can connect.
- Enforce SSH-only remote administration and set an exec-timeout to reduce risk from idle sessions.
- Verify configuration with show commands and troubleshoot a common misconfiguration.
Tip: In production, controlling VTY access prevents unauthorized admin access. Think of the VTY lines as the device's "remote front door" — ACLs are the guest list.
Base Topology (use this exact topology for the lab)
[Internet]
203.0.113.1
|
R1 (Gateway)
Gi0/0: 10.10.10.1
Gi0/1: 10.10.20.1
Gi0/2: 10.10.30.1
/ | \
R2 R3 R4
Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2
Gi0/1: 10.10.40.1 |
/ \ |
S1 S2 S3
/ \ | / \
PC1 PC2 PC3 PC4 PC5
IP scheme reminders (management subnet = VLAN 30):
- Management subnet: 192.168.3.0/24
- Use domain: lab.nhprep.com
- Use password(s): Lab@123
- Organization: NHPREP
Lab Tasks (Try It Yourself First!)
Complete these tasks WITHOUT looking at the solution below. Use
?andshowcommands to figure it out.
Task 1: Enable SSH and create a local admin user
Configure the router so it accepts SSH. Set the domain name to lab.nhprep.com, create a local user named admin with secret Lab@123, and generate RSA keys.
Task 2: Create and apply an ACL to VTY lines
Create a standard IP ACL named MGMT_ONLY that permits only the management subnet (192.168.3.0/24). Apply this ACL inbound to VTY lines so only hosts in that subnet may initiate SSH.
Task 3: Restrict VTY to SSH and set exec-timeout
On VTY lines 0–4, allow only ssh (no telnet), enable login using the local database, and set exec-timeout to 5 minutes (5 0).
Think About It: Why must SSH be enabled and user credentials configured before applying an ACL that blocks other IPs to VTY? What happens if you accidentally lock yourself out?
Lab Solution
Task 1 Solution: Enable SSH and create a local admin user
What we are doing: Prepare the router to accept SSH management sessions by setting the domain name, creating a local administrative user, and generating RSA keys. SSH requires a user database and RSA keys to function.
hostname R1
ip domain-name lab.nhprep.com
username admin secret Lab@123
crypto key generate rsa modulus 1024
What just happened:
hostname R1— sets the device hostname; SSH key generation uses the hostname as part of the key identity.ip domain-name lab.nhprep.com— required by IOS to generate RSA keys; associates the device with the required domain.username admin secret Lab@123— creates a local accountadminwith an encrypted secret used for SSH authentication.crypto key generate rsa modulus 1024— generates RSA keypair needed for SSH. The modulus 1024 is the bit length of the key (sufficient for lab/CCNA-level practice).
Verify:
show run | section username
Expected output:
username admin secret 5 $1$abcd$ExampleEncryptedString
show ip ssh
Expected output (typical):
SSH Enabled - version 1.99
RSA key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Warning: If you do not create local users before applying a restrictive VTY ACL, you may still be able to SSH from permitted hosts, but ensure you have at least one username configured to authenticate.
Task 2 Solution: Create and apply an ACL to VTY lines
What we are doing: Build a standard ACL named MGMT_ONLY that permits only the 192.168.3.0/24 management network, then apply it inbound to VTY lines so only those hosts can initiate remote sessions.
ip access-list standard MGMT_ONLY
permit 192.168.3.0 0.0.0.255
!
line vty 0 4
access-class MGMT_ONLY in
What just happened:
ip access-list standard MGMT_ONLY— enters named standard ACL configuration mode and creates the ACLMGMT_ONLY.permit 192.168.3.0 0.0.0.255— allows any host in 192.168.3.0/24.line vty 0 4— selects virtual terminal lines 0 through 4 (most routers support 5 concurrent remote sessions by default).access-class MGMT_ONLY in— applies the named ACL to inbound connection attempts on VTY lines. This filters by source IP of incoming connection attempts; only permitted sources can begin an SSH session.
Verify:
show ip access-lists
Expected output:
Standard IP access list MGMT_ONLY
10 permit 192.168.3.0 0.0.0.255
show running-config | section line vty
Expected output:
line vty 0 4
access-class MGMT_ONLY in
Task 3 Solution: Restrict VTY to SSH and set exec-timeout
What we are doing: Configure the VTY lines to accept only SSH, require login using the local database, and set an idle timeout to reduce the window for unauthorized use.
line vty 0 4
transport input ssh
login local
exec-timeout 5 0
What just happened:
transport input ssh— disables Telnet and accepts only SSH on VTYs. Telnet is cleartext; disabling it prevents credential exposure.login local— tells the device to authenticate remote logins against the local username database (we createdadminearlier).exec-timeout 5 0— sets the inactivity timeout to 5 minutes and 0 seconds. After this idle period, the session is automatically closed, reducing risk from idle sessions left open on shared consoles.
Verify:
show running-config | section line vty
Expected output:
line vty 0 4
access-class MGMT_ONLY in
transport input ssh
login local
exec-timeout 5 0
show users
Expected output (if no active users):
Line User Host(s) Idle Location
* 0 con 0 00:00:00
(When a permitted management host SSHes in, it will appear here.)
Real-world context: In data centers, restricting management plane access to an out-of-band management VLAN (the management subnet here) prevents attackers on other networks from reaching the device's administrative interfaces.
Troubleshooting Scenario
Scenario: VTY ACL prevents even management hosts from connecting
Symptom: SSH from a host in 192.168.3.10 to R1 is denied; connection times out. Your task: Find and fix the issue. Hint: Check the ACL contents and the source IP of the SSH client.
Solution:
- Likely cause: ACL uses wrong wildcard mask or wrong network (e.g.,
permit 192.168.3.0 255.255.255.0entered instead of wildcard mask). Standard ACLs on IOS use wildcard masks. - Fix: Replace ACL entry with correct wildcard mask.
ip access-list standard MGMT_ONLY
no permit 192.168.3.0 255.255.255.0
permit 192.168.3.0 0.0.0.255
- Verify with
show ip access-liststo ensure correct entry.
Verification Checklist
- SSH is enabled and RSA keys generated (
show ip ssh). - Local user
adminexists (show run | section username). - VTY lines accept only SSH, use local login, have exec-timeout set, and access-class applied (
show running-config | section line vty).
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| SSH attempts time out from management host | ACL uses incorrect wildcard mask or wrong network | Correct ACL entry: permit 192.168.3.0 0.0.0.255 |
| Telnet is still accepted | transport input not set or includes telnet | On VTY: transport input ssh |
| Cannot authenticate over SSH | No local user configured or wrong password | Add local user: username admin secret Lab@123 |
| Locked out after applying ACL | ACL denies your IP and you have no console access | Use console (physical) or correct ACL via console; always test from a permitted host first |
Challenge Task
Configure R2 and R4 so their VTY lines mirror R1: only allow SSH from the management subnet, use the same admin credentials, and set exec-timeout 3 0. Do this without step-by-step guidance; ensure you create RSA keys and verify with show ip ssh and show running-config | section line vty.
Key Takeaways
- Use ACLs on VTY to restrict which IPs can establish remote management sessions.
- Always enable SSH and create local credentials before locking down VTYs.
- Set exec-timeout to automatically close idle sessions and reduce security exposure.
Important: When working on production devices, always plan an out-of-band access method (console/kvm) before enforcing restrictive VTY ACLs to avoid accidental lockout.