Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 4.8 — Configure secure SSH access

SSH provides encrypted remote terminal access. A complete device configuration needs identity, keys, users or AAA, VTY policy, reachable management addressing, and verification that insecure alternatives are rejected.

Device identity and keys

An IOS-style SSH setup commonly needs a hostname and domain name before generating RSA keys. The keys let the server prove possession of its private key and establish protected transport. Choose a key size supported by current organizational and platform policy. Regenerating keys changes host identity and can trigger client warnings, so manage it as a deliberate change.

Select the supported SSH version and disable obsolete behavior where possible.

Authentication source

Create named local users with protected secrets for a small or recovery design, or integrate centralized AAA. Avoid shared accounts. Local login on VTY lines must reference the intended user database; a line password and login is a different, less accountable design.

Maintain a protected break-glass procedure if centralized identity can fail.

VTY transport policy

Virtual terminal lines control remote CLI sessions. Restrict input transport to SSH so Telnet is not accepted. Apply source ACLs to the management path, session timeouts, and authorization according to policy. An SSH server reachable from every network still has an unnecessarily broad attack surface.

IOS command map

A lab sequence uses hostname R1 and ip domain name example.test before crypto key generate rsa, then creates a non-production account with username lab-admin privilege 15 secret <training-secret>. Under line vty 0 4, apply login local and transport input ssh. Use ip ssh version 2 on platforms that offer the selector. Never put a real password or private key in course notes, shell history, or source control.

Use show ip ssh for server version and status, show ssh for active sessions, and show running-config section line vty to confirm authentication and allowed transport without exposing secrets. Test a valid and invalid identity and verify that Telnet is refused. Before source ACL or AAA changes, preserve a separately authorized recovery path.

Routing and source interfaces

The device needs a reachable management address and return route. Central systems may expect a stable source interface. Place management in a dedicated VRF or segment when the architecture uses one, and run tests in that routing context.

Worked configuration plan

For a lab router, set approved hostname and domain, generate supported RSA keys, create a named local administrator with a secret, enable SSH version 2, configure VTY local authentication, and permit only SSH transport. Apply a management-source restriction that preserves the authorized test host. Verify login and command access, then confirm a Telnet attempt is refused.

Verification evidence

Inspect SSH server status and key details without exposing private material, VTY configuration, active sessions, AAA or local authentication logs, source ACL counters, and return routing. Test an allowed identity, a denied identity, an allowed source, a denied source, and the recovery path under controlled conditions.

Common traps

• Generating keys without a stable device identity plan.
• Enabling SSH but leaving Telnet allowed.
• Using one shared username.
• Forgetting return routing or management VRF context.
• Locking out every recovery path with an ACL.

Readiness checklist

• I can list SSH configuration prerequisites.
• I can configure named local authentication and VTY transport.
• I include source restriction and recovery.
• I independently prove SSH works and Telnet does not.