11 hands-on SSH scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. SSH configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
One-branch edge capstone that unifies DHCP for the LAN, PAT overload to an Internet server, an extended ACL that permits HTTP but denies SSH, and SSH-only management. The starting lab intentionally contains multiple faults across DHCP, NAT, and SSH so you must diagnose and repair the edge to achieve full end-to-end verification from the client.
Harden a single-site management LAN by replacing insecure Telnet with SSH-only access on the router. You will generate RSA keys, define a domain name, create a local admin user with a secret, force SSHv2, and restrict VTY lines to SSH with local login. Validate success from an admin workstation and confirm Telnet is refused. The topology is intentionally simple: one router, one access switch, and two hosts on a dedicated management VLAN.
Harden SSH access to a production router by allowing only a designated management workstation to connect. You will apply a standard ACL to the router's VTY lines with access-class, verify that the permitted host can SSH in, and confirm that a second host on the same LAN is refused. End-to-end IP forwarding is pre-built with static routes so the focus stays on management-plane control.
Harden the management plane of a single IOS router by throttling brute-force login attempts and presenting a legal-warning banner. You will enable SSH-based management, configure login block-for and delay to resist password-guessing, and verify behavior from an ADMIN Linux workstation.
Harden a single Cisco IOS router’s management plane using AAA named method lists applied per-line. Create VTY-AUTH (local then enable) to protect remote SSH access without lockout risk, and CONSOLE-AUTH (local only) to secure the console independently. Verify using show/run sections and test SSH from the ADMIN workstation.
Advanced secure-access capstone, run as a fault hunt. A hardening change was rolled back badly overnight: the edge router is reachable but the management plane is wide open in several different ways at once, and an SSH key cannot even be generated. You get symptoms and the required end state — no fault list. Everything is on one device, so the work is knowing which pieces of a management-plane build depend on each other rather than hunting across a topology.
Harden a single IOS router’s management plane and create tiered CLI access using custom privilege levels. Build two local accounts: a full admin (level 15) and a junior operator (level 5). Elevate only specific exec commands to level 5 so the operator can run them without gaining full configuration rights. Verify behavior from a Linux admin workstation over SSH.
Harden R1’s management plane by moving SSH login authentication and exec authorization under the IOS AAA framework using the local user database. You will start from a secure SSH-only baseline that still uses login local, enable aaa new-model, define default AAA methods that point at local, and bind VTY lines to AAA. Success is proven by authenticating from the ADMIN host over SSH and landing at the user’s privilege level.
Harden a Cisco IOS router so remote management is allowed only via SSH. You will remove Telnet from the VTY lines, keep local authentication, and add an idle-session timeout. Verify success from a Linux ADMIN host by confirming SSH works and Telnet is refused.
Bring up secure remote management (SSH) on a single Cisco IOS router using a dedicated management LAN. You will configure the deterministic set of running-config lines that enable SSH with a local admin account, restrict VTY to SSH, and verify from a Linux workstation. RSA key generation is performed as an exec step and is not graded; the grading focuses on the presence of the configuration lines that make SSH functional and secure.
Free with an account
Harden the console and VTY lines on a single Cisco IOS router so idle sessions close automatically and every access path requires authentication. You will configure login local on both console and VTY, set 5-minute exec timeouts, enable logging synchronous on the console, and restrict VTY to SSH. Verification uses show outputs; grading evaluates the deterministic running-config.
Telnet carries your username, password, and every keystroke in clear text, so replacing it with SSH is the first hardening step on any device you care about and a CCNA objective candidates are expected to know cold. It is also the one configuration where a mistake locks you out of the box you are configuring, which on production gear means a console cable and a drive. That combination is why reading the command list is not enough. The commands have an order and a prerequisite, since the RSA key will not generate without a domain name, and the most common failure is a device that looks secured but is not: you harden vty 0 4, never notice the switch also has vty 5 15, and Telnet is still answering on those lines. You find that by checking, not by remembering.
These labs run on real Cisco IOS in Cisco Modeling Labs and walk the whole chain. You set a hostname and ip domain-name, generate the key from privileged EXEC mode with crypto key generate rsa, create a local account with a username and secret, then apply login local and transport input ssh to every vty range the platform actually has, found by reading the running configuration rather than assumed. You force ip ssh version 2, save so the key survives a reload, and restrict which source addresses may connect with a standard ACL applied via access-class in on the vty lines. Console and privileged access get hardened too, with enable secret, exec-timeout, and logging synchronous. Verify with show ip ssh and show ssh, then prove it by logging in from another node. Faults include a missing domain name, login local with no user, and an access-class that denies your management host. Your export is graded requirement by requirement against the answer key.
Because ip domain-name is not configured. IOS rejects the command outright and the message names the only hard prerequisite. Setting a real hostname is still worth doing, since it forms the fully qualified name attached to the generated key, but a device left on the default hostname will generate a key fine as long as a domain name exists. Note that this is an EXEC-mode command, not a configuration-mode one, so it is entered from the enable prompt rather than inside configure terminal.
No. SSH on IOS authenticates with a username and password, so a bare shared line password will not work. The vty lines need login local backed by a local user account, or AAA. That is why the labs create a user with a secret and point the lines at local login. Without a username-based method the router rejects SSH logins even when the RSA key and version 2 are both configured correctly.
No, and virtual devices are the better place to learn this specifically. Each lab is a YAML topology for your own Cisco Modeling Labs instance running free-tier images, so locking yourself out with a bad access-class costs you a node wipe and a re-import rather than a console cable and a site visit. Being able to break management access safely, several times, is the point of doing it here first.
Study the theory behind these labs — the concept explainer and step-by-step guides.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.