SSH Configuration

Lab Objectives

• Configure secure remote management on a router by creating local user credentials and generating RSA keys for SSH.
• Enforce SSH version 2 and disable Telnet on the vty lines so only SSH is allowed.
• Verify SSH operation and demonstrate how to troubleshoot common misconfigurations.

Topology (use this exact diagram and IPs 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 used in this lab:

• 10.10.10.0/24 — R1-R2 link
• 10.10.20.0/24 — R1-R3 link
• 10.10.30.0/24 — R1-R4 link
• 10.10.40.0/24 — R2-S1 link
• 192.168.1.0/24 — VLAN 10 (Sales)
• 192.168.2.0/24 — VLAN 20 (Engineering)
• 192.168.3.0/24 — VLAN 30 (Management)
• 203.0.113.0/24 — Public/Internet simulation

Tip: In production networks, SSH is used for encrypted device management. Telnet sends credentials in clear text and is unacceptable on networks that require confidentiality and compliance.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Create local administrative user

Create a local user account named admin with privilege level 15 and the password Lab@123. This account will be used for SSH login.

Task 2: Generate RSA keys and set domain name

Set the router domain name to lab.nhprep.com and generate an RSA key pair with a modulus of 1024 bits so the router can act as an SSH server.

Task 3: Configure SSH v2 and disable Telnet

Enable SSH version 2 on the router, tune SSH timeout and retry settings (optional but recommended), and modify the vty lines to accept only SSH (disable Telnet) using local login.

Think About It: Why does SSH require a domain name (or key label) and RSA keys, while Telnet does not? How does this affect the sequence of configuration commands?

---

Lab Solution

Task 1 Solution: Create local administrative user

What we are doing: We create a local account named admin with privilege 15 and a secret password. SSH uses device-local authentication if no external AAA server is present. The secret is stored as an encrypted hash.

R1# configure terminal
R1(config)# username admin privilege 15 secret Lab@123
R1(config)# end

What just happened:

• configure terminal — enters global configuration mode.
• username admin privilege 15 secret Lab@123 — creates the local user admin with full privileges (privilege 15). Using secret stores the password as a hashed secret (more secure than password).
• end — exits configuration mode.

Verify:

R1# show running-config | include username
username admin privilege 15 secret 5 $1$abcd$ABCDEFGhijklmnopqrsTUV

Expected: you will see a username admin line. The secret will appear as an encrypted hash (value will differ on your device).

Why this matters: SSH authentication must reference a valid login method. If vty is configured to login local and no local user exists, logins will fail.

---

Task 2 Solution: Generate RSA keys and set domain name

What we are doing: SSH requires an RSA key pair for public-key cryptography. Cisco IOS generates this key pair and ties it to the device domain name. We configure the domain name first, then generate a 1024-bit RSA key.

R1# configure terminal
R1(config)# ip domain-name lab.nhprep.com
R1(config)# crypto key generate rsa modulus 1024
% The name for the keys will be: R1.lab.nhprep.com
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
R1(config)# end

What just happened:

• ip domain-name lab.nhprep.com — sets the device domain used to label the RSA key. The key name usually becomes hostname.domain.
• crypto key generate rsa modulus 1024 — generates an RSA key pair with 1024-bit modulus. SSH needs this key to perform the key exchange and encryption.
• The device reports successful key generation.

Verify:

R1# show crypto key mypubkey rsa
% Key pair was generated at: 00:12:34 UTC Tue Apr  1 2025
Key name: R1.lab.nhprep.com
Key type: RSA
Key size: 1024 bits
Usage: General Purpose
% End

And:

R1# show running-config | include ip domain-name
ip domain-name lab.nhprep.com

Why this matters: Without an RSA key pair, there is no server identity for SSH and clients cannot establish a secure connection. The domain name provides a stable key label.

---

Task 3 Solution: Configure SSH v2 and disable Telnet

What we are doing: Set SSH to use version 2 (more secure), optionally adjust SSH timeout and retries, and restrict vty lines to accept only SSH with local authentication.

R1# configure terminal
R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 2
R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 5 0
R1(config-line)# end

What just happened:

• ip ssh version 2 — forces the SSH server to use SSH protocol version 2 (improved security and features vs. version 1).
• ip ssh time-out 60 — sets SSH authentication timeout to 60 seconds to give slow clients time to respond.
• ip ssh authentication-retries 2 — limits authentication retries to 2; reduces brute-force exposure.
• line vty 0 4 — selects all virtual terminal (remote) lines.
• login local — makes vty use the local username database for authentication.
• transport input ssh — allows only SSH connections on vty; Telnet is disabled.
• exec-timeout 5 0 — sets idle session timeout (5 minutes, 0 seconds).

Verify:

R1# show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 60 secs; Authentication retries: 2
Available SSH keypairs:
  Keyname: R1.lab.nhprep.com (RSA, 1024 bits)

And:

R1# show running-config | section line vty
line vty 0 4
 exec-timeout 5 0
 login local
 transport input ssh

To confirm Telnet is disabled from a remote client, attempting a Telnet session to R1 should fail (no listener on port 23). A successful SSH attempt will prompt for username/password.

Important: Enforcing SSH v2 and transport input ssh closes the insecure Telnet vector and ensures encrypted management sessions.

---

Troubleshooting Scenario

Scenario: vty still allows Telnet despite configuration

Symptom: Administrators can still connect via Telnet to R1 (cleartext), or show running-config | section line vty doesn't show transport input ssh.
Your task: Find and fix the issue.
Hint: Check whether your line vty configuration replaced a different transport command or whether transport input was mis-typed.

Solution:

• Problem likely due to transport input all or transport input telnet still present. Re-enter line configuration and set transport input ssh.

R1# configure terminal
R1(config)# line vty 0 4
R1(config-line)# transport input ssh
R1(config-line)# end

Explanation: Setting transport input ssh explicitly removes telnet from the accepted protocols. Verify with show running-config | section line vty to confirm.

Verification Checklist

• Local user admin exists with privilege 15.
• RSA key generated and associated with lab.nhprep.com.
• ip ssh version 2 configured and timeouts/retries set.
• vty lines configured with login local and transport input ssh.
• Confirmed you can SSH to the router and Telnet is refused.

Common Mistakes

Symptom	Cause	Fix
SSH connection is refused	No RSA key generated (or generated before domain was set)	Set ip domain-name lab.nhprep.com then crypto key generate rsa modulus 1024
Login fails after SSH prompts for credentials	No local user or login local not configured on vty	Create username admin privilege 15 secret Lab@123 and set line vty 0 4 -> login local
Telnet still works	transport input left as all or telnet	On vty lines run transport input ssh
SSH uses version 1	ip ssh version 2 not configured	Configure ip ssh version 2 and regenerate keys if needed

Challenge Task

Configure SSH the same way on R2, then from PC1 (attached via S1) initiate an SSH connection to R2 using admin and Lab@123. Additionally, restrict SSH access on R2 so only hosts in 10.10.10.0/24 can reach its vty using an access-class (apply inbound ACL to vty). (No step-by-step; determine the ACL and vty binding yourself.)