SSH Remote Management Lab

---

Overview

Telnet was the original protocol for remote router administration — but it transmits everything in plaintext, including usernames and passwords. Anyone with a packet sniffer on the network can capture administrator credentials in seconds.

SSH (Secure Shell) replaced Telnet by encrypting all communication between the administrator and the network device. This lab configures SSH version 2 on a Cisco router from scratch — generating RSA keys, creating local user accounts, configuring VTY lines, and testing authenticated encrypted remote access.

This is a foundational security hardening skill — the same configuration is applied to every router and switch in a properly secured enterprise network.

---

Network Topology

PC0 ──────── Switch0 ──────── Router0
192.168.1.10              192.168.1.1
              Admin connects via SSH
              ssh -l alex 192.168.1.1

Device	Interface	IP Address	Subnet Mask	Gateway
PC0	FastEthernet0	192.168.1.10	255.255.255.0	192.168.1.1
Router0	G0/0	192.168.1.1	255.255.255.0	N/A

---

SSH Configuration — Step by Step

Step 1 — Set Hostname and Domain Name

enable
configure terminal
hostname Router0
ip domain-name lab.local

Why domain name? SSH requires a domain name to generate RSA keys — the key is named Router0.lab.local

Step 2 — Create Local User Account

username alex privilege 15 secret Str0ngP@ssw0rd

Note: privilege 15 grants full administrative access. In production, use lower privilege levels and role-based access control.

Step 3 — Generate RSA Keys

crypto key generate rsa modulus 2048

Why 2048 bits? RSA key length determines encryption strength. 1024-bit keys are no longer considered secure. NIST recommends 2048-bit minimum, 4096-bit for high-security environments.

Step 4 — Enable SSH Version 2

ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

SSH version 1 has known vulnerabilities. Always use version 2.

Step 5 — Configure VTY Lines for SSH Only

line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0

Critical: transport input ssh blocks Telnet entirely — only SSH connections are accepted on VTY lines.

Step 6 — Disable Telnet on Console (Hardening)

line console 0
 login local
 exec-timeout 5 0

Full Configuration

enable
configure terminal

! Identity
hostname Router0
ip domain-name lab.local

! Local authentication
username alex privilege 15 secret Str0ngP@ssw0rd

! RSA key generation
crypto key generate rsa modulus 2048

! SSH hardening
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

! VTY lines — SSH only
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0

! Interface
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 no shutdown

end
write memory

Full config available in config/.

---

Verification

show ip ssh                    ! Confirm SSH version, timeout, auth retries
show ssh                       ! View active SSH sessions
show running-config | section ssh    ! Review SSH-specific config
show running-config | section line vty    ! Verify VTY transport input
show ip interface brief        ! Confirm interface is up

Testing SSH from PC0 (Packet Tracer)

! In PC0 Command Prompt
ssh -l alex 192.168.1.1
! Enter password when prompted
! Successful login lands in Router0 privileged exec mode

---

Troubleshooting

Issue 1 — SSH Connection Refused

Symptom: ssh -l alex 192.168.1.1 returned "Connection refused."
Root Cause: RSA keys had not been generated — SSH cannot function without them.
Resolution: Ran crypto key generate rsa modulus 2048. SSH service started. Connection accepted.
Lesson: SSH requires RSA keys to be generated AND a domain name to be set before it will accept connections.

Issue 2 — Authentication Failure

Symptom: Correct password entered but login failed with "Authentication failed."
Root Cause: VTY lines were configured with login instead of login local — the router was looking for a password on the VTY line itself, not the local user database.
Resolution: Changed to login local on VTY lines. Authentication against the username alex account succeeded.

Issue 3 — Telnet Still Working After SSH Configuration

Symptom: Even after configuring SSH, Telnet connections were still being accepted.
Root Cause: transport input ssh was not configured — VTY lines accepted all protocols by default.
Resolution: Added transport input ssh to all VTY lines. Telnet connections now refused. SSH-only access confirmed.

---

Telnet vs SSH Comparison

Feature	Telnet	SSH v2
Encryption	None — plaintext	AES, 3DES encrypted
Authentication	Password only	Password + RSA key support
Port	TCP 23	TCP 22
Credential exposure	Visible in packet capture	Encrypted — not visible
NIST recommendation	Deprecated	Required
Use in production	Never	Always

---

Security Relevance

SSH configuration is one of the most fundamental network security hardening tasks:

Why This Matters:

• Every unprotected Telnet session is a credential theft opportunity for any attacker with network access
• SSH brute-force attacks against TCP port 22 are among the most common automated attacks on the internet (this is exactly what the SSH Brute Force Detection Lab defends against)
• Proper SSH hardening — strong RSA keys, SSH v2 only, authentication retries limit, exec timeout — directly reduces attack surface

MITRE ATT&CK Relevance:

• T1110 (Brute Force) — weak SSH configuration enables credential brute-forcing
• T1021.004 (SSH — Remote Services) — attackers use SSH for lateral movement after obtaining credentials
• T1040 (Network Sniffing) — Telnet credentials captured via packet capture; SSH prevents this

Framework Mapping:

• NIST SP 800-53 AC-17 (Remote Access) — requires encrypted, authenticated remote access
• NIST SP 800-53 IA-2 (Identification and Authentication) — local user account authentication
• CIS Control 4.1 — use encrypted protocols for remote administration

Connection to Other Labs: This lab shows the correct SSH configuration. The SSH Brute Force Detection Lab shows what happens when SSH is exposed without proper protections — and how to detect and defend against brute-force attacks using Fail2Ban.

---

Skills Demonstrated

Skill	Details
SSH v2 Configuration	Full end-to-end SSH setup on Cisco IOS from scratch
RSA Key Generation	Generated 2048-bit RSA keys for SSH encryption
Local Authentication	Created privilege-level user accounts for router access
VTY Hardening	Restricted VTY lines to SSH-only, disabled Telnet
SSH Troubleshooting	Diagnosed missing RSA keys, wrong login method, Telnet still active
Telnet vs SSH	Documented security differences and NIST deprecation of Telnet
Security Framework Mapping	NIST AC-17, IA-2, MITRE T1110, T1021.004
Cisco IOS CLI	Full configuration and verification via command line

---

Author

Alex Ojo — Cybersecurity Student | Network Security Enthusiast
🔗 GitHub | LinkedIn | Portfolio