SSH Configuration & Telnet Hardening (Cisco IOS)

Telnet sends all data — including usernames and passwords — as plain text across the network. Anyone running a packet capture tool such as Wireshark on the same network can read every character you type. SSH (Secure Shell) encrypts the entire session, making it the only acceptable protocol for remote management of Cisco routers and switches in any production environment. For a conceptual overview, see SSH and SSH & Telnet Security.

This lab covers the complete process of enabling SSHv2 on a Cisco device — from prerequisites (hostname, domain name, RSA keys) through VTY line hardening and final verification. Before starting, make sure Hostname, Password, and Banner Configuration and Console & VTY Line Configuration are already in place.

SSH vs Telnet — Why It Matters

Feature	Telnet	SSH
Encryption	❌ None — plain text	✅ Full session encryption
TCP Port	23	22
Password visibility	Visible in a packet capture	Encrypted — unreadable in a capture
Authentication	Password only	Password or public key authentication. See AAA Authentication Methods.
Use in production	❌ Never	✅ Always
CCNA exam relevance	Know why it is insecure	Know how to configure SSHv2

SSH Versions

Version	Status	Notes
SSHv1	⚠️ Legacy — deprecated	Known security vulnerabilities. Some older IOS versions default to v1. Always force v2.
SSHv2	✅ Current standard	Stronger encryption, improved integrity checking. Required for CCNA compliance.

SSH Prerequisites on Cisco IOS

SSH on Cisco IOS requires three items to be configured before RSA keys can be generated. If any of these are missing, the crypto key generate rsa command will either fail or produce a non-functional result:

Requirement	Command	Why Required
Hostname (not default)	`hostname NetsTuts_R1`	The RSA key name is derived from `hostname.domain-name`. A default hostname (Router/Switch) produces a generic key name. See Hostname, Password, and Banner Configuration.
Domain name	`ip domain-name netstuts.com`	Required to complete the FQDN used in key generation. Without it, `crypto key generate rsa` may fail.
Local user account	`username admin privilege 15 secret ...`	SSH requires `login local` on VTY lines — a local user must exist for authentication to succeed. See Console & VTY Line Configuration.

Lab Scenario

In this lab, NetsTuts_R1 will be fully configured for SSHv2 access with Telnet completely disabled:

Parameter	Value
Device hostname	`NetsTuts_R1`
Domain name	`netstuts.com`
RSA key size	2048 bits
SSH version	2 (forced)
Authentication timeout	60 seconds
Max authentication retries	3
VTY transport	SSH only (Telnet disabled). See Console & VTY Line Configuration.
Local username	`admin` / privilege 15

Step 1: Configure Prerequisites

Set the hostname, domain name, and local user account before generating RSA keys. If your device already has these from a previous lab, skip to Step 2.

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
NetsTuts_R1(config)#hostname NetsTuts_R1
NetsTuts_R1(config)#ip domain-name netstuts.com
NetsTuts_R1(config)#username admin privilege 15 secret Admin@Secure1!

Hostname, domain name, and local user configured. The RSA key will be named NetsTuts_R1.netstuts.com — the FQDN of the device. See Hostname, Password, and Banner Configuration for full details on these prerequisite commands.

Privilege level 15 grants full administrative access — equivalent to being in Privileged EXEC mode immediately after login. See Login Authentication Methods for a full explanation of privilege levels.

Step 2: Generate RSA Keys

RSA keys are the cryptographic foundation of SSH on Cisco IOS. The key pair (public + private) is used to establish the encrypted session. A larger key size provides stronger encryption — 2048 bits is the current recommended minimum. Keys smaller than 768 bits do not support SSHv2.

NetsTuts_R1(config)#crypto key generate rsa modulus 2048
The name for the keys will be: NetsTuts_R1.netstuts.com
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 3 seconds)
NetsTuts_R1(config)#

IOS confirms the key name (NetsTuts_R1.netstuts.com) and size (2048 bits). Key generation may take a few seconds — this is normal.

RSA Key Size Guide

Modulus Size	SSH Version Support	Recommendation
512 bits	SSHv1 only	❌ Too weak — never use
768 bits	SSHv1 and SSHv2	⚠️ Minimum for SSHv2 — below current standards
1024 bits	SSHv1 and SSHv2	⚠️ Acceptable but not ideal
2048 bits	SSHv2	✅ Recommended minimum for production
4096 bits	SSHv2	✅ Maximum security — slower key generation

To delete RSA keys (for example, if you need to regenerate them with a different size or after changing the hostname):

NetsTuts_R1(config)#crypto key zeroize rsa

This immediately destroys all RSA keys and disables SSH until new keys are generated.

Step 3: Force SSHv2

After generating RSA keys, Cisco IOS enables SSH but may allow both SSHv1 and SSHv2 connections. You must explicitly force version 2 to prevent clients from negotiating the weaker v1:

NetsTuts_R1(config)#ip ssh version 2

Forces the device to only accept SSHv2 connections. Any SSHv1 connection attempt will be rejected.

Additional SSH Hardening Parameters

NetsTuts_R1(config)#ip ssh time-out 60
NetsTuts_R1(config)#ip ssh authentication-retries 3

ip ssh time-out 60 — SSH negotiation must complete within 60 seconds. ip ssh authentication-retries 3 — after 3 failed login attempts, the connection is dropped. See show logging to review connection failure events captured by syslog.

Command	Default	Recommended	Purpose
`ip ssh version 2`	Both v1 and v2	v2 only	Prevents weak SSHv1 connections
`ip ssh time-out 60`	120 seconds	60 seconds	Reduces window for incomplete connection attacks
`ip ssh authentication-retries 3`	3	2–3	Limits brute-force attempts per connection. See Brute-Force Protection

Step 4: Configure VTY Lines for SSH Only

Generating RSA keys and setting ip ssh version 2 makes SSH available on the device, but VTY lines control what is actually accepted for remote connections. You must set transport input ssh to explicitly disable Telnet and enforce SSH as the only allowed protocol. For full VTY line options including access-class ACLs, see Console & VTY Line Configuration.

NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#login local
NetsTuts_R1(config-line)#transport input ssh
NetsTuts_R1(config-line)#exec-timeout 10 0
NetsTuts_R1(config-line)#logging synchronous
NetsTuts_R1(config-line)#exit
NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

VTY lines accept SSH only. Telnet connections will be refused. login local requires credentials from the local user database. logging synchronous prevents syslog messages from interrupting CLI input — see Syslog Configuration for syslog setup. Save the completed configuration with copy run start.

Disabling Telnet completely: transport input ssh is sufficient to block Telnet. Some engineers also add transport output ssh to prevent the device from initiating Telnet connections to other devices — a useful additional control in high-security environments.

Step 5: Complete SSH Baseline Configuration

The following is the complete SSH configuration from start to finish for NetsTuts_R1:

! ══════════════════════════════════════════════════════════
! NetsTuts SSH Hardening Baseline — NetsTuts_R1
! ══════════════════════════════════════════════════════════

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Prerequisites ─────────────────────────────────────────
NetsTuts_R1(config)#hostname NetsTuts_R1
NetsTuts_R1(config)#ip domain-name netstuts.com
NetsTuts_R1(config)#username admin privilege 15 secret Admin@Secure1!

! ── Generate RSA keys ─────────────────────────────────────
NetsTuts_R1(config)#crypto key generate rsa modulus 2048

! ── SSH hardening ─────────────────────────────────────────
NetsTuts_R1(config)#ip ssh version 2
NetsTuts_R1(config)#ip ssh time-out 60
NetsTuts_R1(config)#ip ssh authentication-retries 3

! ── VTY lines: SSH only ───────────────────────────────────
NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#login local
NetsTuts_R1(config-line)#transport input ssh
NetsTuts_R1(config-line)#exec-timeout 10 0
NetsTuts_R1(config-line)#logging synchronous
NetsTuts_R1(config-line)#exit

! ── Save ──────────────────────────────────────────────────
NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

This baseline is the prerequisite for SSH-dependent tools such as Python Netmiko and NAPALM. See Saving & Managing Cisco Configurations to ensure the configuration persists after a reload.

6. Verification

show ip ssh

Confirms SSH is enabled, the version, timeout, and retry settings:

NetsTuts_R1#show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 60 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): NetsTuts_R1.netstuts.com

SSH Enabled - version 2.0 confirms SSHv2 is active. If this shows version 1.99, SSHv1 is still being accepted — verify ip ssh version 2 is in the running config with show running-config | section ssh.

show ssh

Shows all currently active SSH sessions:

NetsTuts_R1#show ssh
%No SSHv1 server connections running.
Connection Version Mode Encryption  Hmac         State          Username
0          2.0     IN   aes256-ctr  hmac-sha2-256 Session started admin
0          2.0     OUT  aes256-ctr  hmac-sha2-256 Session started admin

One active SSHv2 session by user admin. Encryption: AES-256-CTR. Integrity: HMAC-SHA2-256. The "No SSHv1 server connections running" line confirms v1 is disabled.

show crypto key mypubkey rsa

Verifies RSA keys were generated successfully and shows the key name and size:

NetsTuts_R1#show crypto key mypubkey rsa
% Key pair was generated at: 00:01:14 UTC Mar 1 1993
Key name: NetsTuts_R1.netstuts.com
Key type: RSA KEYS
 Storage Device: not specified
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30820122 300D0609 2A864886 F70D0101 01050003 82010F00 ...

Key name confirms the hostname and domain name are correctly set. "Key is not exportable" is the secure default.

show running-config | section ssh

NetsTuts_R1#show running-config | section ssh
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

Use show running-config filtered by section to audit all SSH-related configuration lines in one view.

Verify from a Client — SSH Connection Test

From another Cisco device on the network, use the built-in SSH client to test connectivity. First confirm reachability with ping, then attempt SSH:

NetsTuts_PC1#ssh -l admin 192.168.1.1
Password:

***Unauthorized access is strictly prohibited.***

NetsTuts_R1>

ssh -l [username] [IP] connects to the target device via SSH. The MOTD banner appears after successful authentication. You are now in a fully encrypted remote session.

Verify Telnet is Blocked

NetsTuts_PC1#telnet 192.168.1.1
Trying 192.168.1.1 ...
% Connection refused by remote host

Telnet is refused immediately — transport input ssh on the VTY lines is working correctly.

Verification Command Summary

Command	What It Confirms
`show ip ssh`	SSH version, timeout, retries — confirms SSHv2 is active
`show ssh`	Active SSH sessions, encryption cipher, and authenticated username
`show crypto key mypubkey rsa`	RSA key name, size, and generation status
`show running-config \| section ssh`	All SSH-related configuration lines in running config
`show running-config \| section line vty`	Confirms `transport input ssh` and `login local` on VTY
`ssh -l [user] [IP]`	End-to-end test — confirms SSH connects and Telnet is blocked
`ping [IP]`	Verify IP reachability before troubleshooting SSH connectivity

7. Troubleshooting SSH Issues

Problem	Symptom	Cause	Fix
SSH not available	`show ip ssh` shows "SSH disabled"	RSA keys not generated, or hostname/domain name missing	Set `ip domain-name`, verify hostname is not default, then run `crypto key generate rsa modulus 2048`. See Hostname Configuration.
SSHv1 still accepted	`show ip ssh` shows "version 1.99"	`ip ssh version 2` not configured	Add `ip ssh version 2` to the configuration. Verify with `show running-config \| section ssh`.
Authentication fails	Username and password rejected every time	No local user exists, or `login local` not set on VTY	Verify user with `show running-config \| section username`; confirm `login local` on VTY lines. See VTY Line Configuration.
Connection refused	SSH client reports connection refused or times out	Management IP not reachable, or ACL blocking the source IP	Ping the device IP first; check VTY ACL with `show ip access-lists`. See Standard ACL Configuration for VTY ACL setup.
Telnet still accepted	Telnet connects successfully when it should be blocked	`transport input ssh` not applied, or applied to wrong VTY range	Check all VTY ranges with `show running-config \| section line vty`
RSA keys deleted accidentally	SSH stops working after a configuration change	`crypto key zeroize rsa` was run, or hostname/domain changed after key generation	Regenerate with `crypto key generate rsa modulus 2048`. Check `show logging` for clues about when the change occurred.

Important: If you change the hostname or domain name after generating RSA keys, the existing keys become orphaned under the old FQDN name. You must zeroize and regenerate:

NetsTuts_R1(config)#crypto key zeroize rsa
NetsTuts_R1(config)#crypto key generate rsa modulus 2048

After regenerating, save the configuration immediately with wr.

Key Points & Exam Tips

Telnet sends all data as plain text on TCP port 23 — never use it in production. SSH uses TCP port 22 and encrypts the entire session. See SSH & Telnet Security for a full comparison.
SSH requires three prerequisites before RSA keys can be generated: a non-default hostname, an ip domain-name, and a local user account. See Hostname, Password, and Banner Configuration.
RSA key size must be at least 768 bits to support SSHv2. The current recommended minimum is 2048 bits.
Always force SSHv2 with ip ssh version 2 — without it, the device may accept SSHv1 connections which have known vulnerabilities.
show ip ssh is the primary verification command — it shows the SSH version, timeout, and retry count. Version 1.99 means both v1 and v2 are accepted — version 2.0 means v2 only.
transport input ssh on VTY lines is what actually blocks Telnet — generating RSA keys alone does not disable Telnet. Always configure all VTY line ranges. See Console & VTY Line Configuration.
If you change the hostname or domain name after generating RSA keys, you must crypto key zeroize rsa and regenerate.
ip ssh authentication-retries 3 limits failed login attempts — pair this with login block-for for full brute-force protection.
Use show ssh to see active sessions including the encryption cipher — aes256-ctr with hmac-sha2-256 is the current strong standard.
Test both directions after configuration: confirm SSH connects successfully and confirm Telnet is actively refused.
This SSH configuration is a prerequisite for automation tools: Python Netmiko, NAPALM, and RADIUS/TACACS+ centralised authentication all depend on SSH being correctly configured.

Next Steps: With SSH configured, the next lab is Saving & Managing Cisco Configurations to ensure all this work is preserved correctly. For brute-force protection on login attempts, see Login Brute-Force Protection. For centralised authentication replacing local accounts, see AAA Authentication Methods, RADIUS Configuration, and TACACS+ Configuration. For applying an ACL to restrict which IPs can access the VTY lines, see Standard ACL Configuration. For forwarding SSH violation events to a syslog server, see Syslog Configuration. For SSH-dependent automation workflows, see Python Netmiko and Python NAPALM.

TEST WHAT YOU LEARNED

1. An engineer runs `crypto key generate rsa modulus 2048` but receives an error. The hostname is `NetsTuts_R1` but no domain name is set. What will IOS do?

A. Generate the key using the hostname alone B. Fail or prompt for a domain name — the FQDN (hostname.domain) is required for key naming C. Generate the key and enable SSHv1 automatically D. Use the default domain cisco.com automatically

Correct answer is B. Cisco IOS uses hostname.domain-name as the RSA key name. Without ip domain-name configured, IOS cannot construct the FQDN and the key generation will fail or produce a warning. Always set the domain name before generating RSA keys. See Hostname, Password, and Banner Configuration.

2. After configuring SSHv2 and RSA keys, `show ip ssh` displays "version 1.99". What does this mean and how should it be fixed?

A. The device is running SSHv2 correctly — 1.99 is the internal version number for v2 B. The RSA key size is too small and must be regenerated C. Both SSHv1 and SSHv2 are accepted — ip ssh version 2 must be added to force v2 only D. The domain name is incorrect and must be reconfigured

Correct answer is C. Version "1.99" means the device is in compatibility mode — it accepts both SSHv1 and SSHv2 connections. To force SSHv2 only (which is required for security compliance), add ip ssh version 2 to the configuration. After this, show ip ssh will display "version 2.0". Verify with show running-config | section ssh.

3. An engineer generates RSA keys with a 512-bit modulus. What problem will this cause?

A. SSH will not enable at all B. The device will require a reload before SSH works C. Telnet will be automatically enabled as a fallback D. Only SSHv1 will be supported — keys must be at least 768 bits to support SSHv2

Correct answer is D. SSHv2 requires a minimum RSA key modulus of 768 bits. A 512-bit key can only support SSHv1, which has known security vulnerabilities. The current recommended minimum is 2048 bits. Use crypto key zeroize rsa then regenerate with modulus 2048.

4. RSA keys were generated successfully on `NetsTuts_R1.netstuts.com`. The hostname is then changed to `NetsTuts_Core1`. What must the engineer do to restore SSH functionality?

A. Zeroize the existing RSA keys and regenerate them under the new hostname B. Reload the device — IOS updates keys automatically on reload C. Re-enter ip ssh version 2 to rebind the keys D. Nothing — the keys remain valid regardless of hostname changes

Correct answer is A. RSA keys are named using the device FQDN at the time of generation. When the hostname changes, the existing keys become orphaned under the old name. SSH will stop working. You must run crypto key zeroize rsa to delete the old keys, then crypto key generate rsa modulus 2048 to create new ones under the updated FQDN. See Hostname Configuration for hostname change procedures.

5. What is the difference between `transport input ssh` and `ip ssh version 2`?

A. They do the same thing — either one is sufficient to fully secure SSH B. transport input ssh sets the SSH version; ip ssh version 2 restricts VTY access C. transport input ssh disables Telnet on VTY lines; ip ssh version 2 forces the device to only accept SSHv2 connections D. ip ssh version 2 applies to physical interfaces; transport input ssh applies to routing protocols

Correct answer is C. These are two separate commands serving different purposes. transport input ssh is configured under the VTY line (see Console & VTY Line Configuration) and determines which protocols are accepted for remote connections — setting it to SSH blocks Telnet. ip ssh version 2 is a global command that forces the SSH server to only accept SSHv2 — without it, the device may still accept the weaker SSHv1.

6. An engineer tries to Telnet into a device after configuring `transport input ssh` on VTY lines 0–4, but Telnet still connects successfully. What is the most likely cause?

A. The RSA keys are overriding the transport setting B. The device has VTY lines 5–15 that are not configured — Telnet is connecting on those unconfigured lines C. ip ssh version 2 must also be set to block Telnet D. transport input ssh only applies to outbound connections

Correct answer is B. If the device supports VTY lines 0–15 and only lines 0–4 have transport input ssh configured, lines 5–15 retain their default settings and may still accept Telnet. Always apply security settings to all VTY line ranges. Check with show running-config | section line vty. See Console & VTY Line Configuration for applying settings to all VTY ranges.

7. Which command confirms the RSA key name, size, and whether the key is exportable?

A. show ip ssh B. show ssh C. show running-config | section ssh D. show crypto key mypubkey rsa

Correct answer is D. show crypto key mypubkey rsa displays the RSA key details including the key name (FQDN), key type, and whether it is exportable. show ip ssh shows SSH configuration parameters. show ssh shows active sessions.

8. What does `ip ssh authentication-retries 3` do, and why is it a security improvement?

A. Drops the SSH connection after 3 failed authentication attempts — reduces the effectiveness of brute-force attacks per session B. Locks the user account permanently after 3 failures C. Requires the user to re-authenticate every 3 minutes D. Retries the SSH connection automatically if it drops

Correct answer is A. ip ssh authentication-retries 3 limits the number of failed login attempts within a single SSH session to 3. After 3 failures, the connection is dropped and the attacker must reconnect. This slows down brute-force attacks. For stronger protection, pair it with login block-for to temporarily block all login attempts after a threshold is reached.

9. A network engineer needs to verify which encryption cipher and HMAC algorithm an active SSH session is using. Which command provides this information?

A. show ip ssh B. show crypto key mypubkey rsa C. show ssh D. show running-config | section line vty

Correct answer is C. show ssh displays details of active SSH sessions including the SSH version, the encryption cipher (e.g., aes256-ctr), the HMAC algorithm (e.g., hmac-sha2-256), the session state, and the authenticated username. This is the command to use when verifying the security strength of a live connection.

10. An SSH client reports "Connection refused" when attempting to connect to a router. The engineer confirms the router IP is reachable via ping. What should be checked first?

A. Whether the enable secret is configured B. Whether RSA keys exist, transport input ssh is set on VTY lines, and whether a VTY ACL is blocking the source IP C. Whether the correct username was used D. Whether the Telnet service is running

Correct answer is B. "Connection refused" before any authentication prompt means SSH is not reaching the login stage. The most common causes are: RSA keys were never generated (show ip ssh), transport input ssh is not set on VTY lines (show run | section line vty), or a VTY ACL is blocking the source IP (show ip access-lists). See Standard ACL Configuration for VTY ACL details. Check all three systematically.

Back to Home