How to Configure SSH on a Cisco Router: Secure Remote Access Setup and Best Practices

SSH is the protocol I reach for by default whenever I need to remotely manage a Cisco device, and it should be yours too. Unlike Telnet, SSH encrypts the entire session, which means credentials, commands, and output are all protected from anyone eavesdropping on the network. In this guide, I will walk through the full process of enabling SSH on a Cisco router, from the underlying cryptography to the exact commands you need, plus verification, security hardening, and troubleshooting.

What Is SSH?

SSH, or Secure Shell, is a cryptographic network protocol that provides encrypted remote access to a device’s command line, replacing the plaintext Telnet protocol. SSH operates over TCP port 22 by default and uses public-key cryptography during session establishment to authenticate the server (and optionally the client), followed by symmetric encryption for the actual data exchange, which is far more efficient for ongoing traffic.

Cisco IOS supports SSH versions 1 and 2, though SSH version 1 has known vulnerabilities and should never be used. SSH version 2 is the standard for any modern deployment.

How SSH Works: Protocol Operation

SSH session establishment happens in several distinct phases:

1. TCP handshake – client connects to the router on TCP port 22.
2. Protocol version negotiation – client and server agree on SSH version (should always be v2).
3. Key exchange – the router presents its RSA (or other) host key, and both sides negotiate a shared session key using an algorithm like Diffie-Hellman, without ever transmitting the actual secret over the wire.
4. Encryption established – all further communication is encrypted using a symmetric cipher (such as AES) derived from the exchanged keys.
5. Authentication – the client authenticates using a username/password or public key, now protected by the already-established encryption.
6. Session begins – an encrypted interactive CLI session starts, functionally identical to what Telnet provides, but fully protected.

This is the core reason SSH is dramatically more secure than Telnet — authentication itself happens only after encryption is already in place.

Lab Topology

[Admin PC 10.0.0.5] --- [Switch] --- G0/0 [Router R1]

Prerequisites for SSH

Before SSH will function, three things must be configured on the router:

1. A hostname (other than the default “Router”)
2. A domain name
3. RSA keys generated for encryption

Step-by-Step SSH Configuration

Router> enable
Router# configure terminal
Router(config)# hostname R1
R1(config)# ip domain-name awjunaid.local
R1(config)# crypto key generate rsa modulus 2048
The name for the keys will be: R1.awjunaid.local
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 3 seconds)

Now create a local user account and enable SSH version 2:

R1(config)# username admin privilege 15 secret C1sc0Adm!nP@ss
R1(config)# ip ssh version 2

Configure the VTY lines to use SSH exclusively, with local authentication:

R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# exec-timeout 10 0
R1(config-line)# exit

Optionally, harden SSH parameters further:

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

Verification

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

R1# show crypto key mypubkey rsa
% Key pair was generated at: 08:15:32 UTC Jul 29 2026
Key name: R1.awjunaid.local
Key type: RSA KEYS
Storage Device: not specified
Usage: General Purpose Key
Key is not exportable.
Key Data:
  30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 02820101 ...

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

From the admin PC:

C:\> ssh -l admin 10.0.0.1
Password:
R1#

Real-World Enterprise Scenario

In an enterprise environment, SSH is virtually always the mandated remote access protocol for network devices, often enforced by security policy and validated during compliance audits (PCI-DSS, ISO 27001, and similar frameworks explicitly call out plaintext protocols like Telnet as violations). A typical enterprise rollout combines SSH with TACACS+ or RADIUS for centralized authentication instead of local usernames, so that access can be logged, audited, and revoked centrally rather than managing individual local accounts across hundreds of devices:

R1(config)# aaa new-model
R1(config)# tacacs server TACACS1
R1(config-server-tacacs)# address ipv4 10.0.0.100
R1(config-server-tacacs)# key TacacsSharedKey123
R1(config-server-tacacs)# exit
R1(config)# aaa authentication login default group tacacs+ local
R1(config)# aaa authorization exec default group tacacs+ local

This ensures that even SSH access is tied to centrally managed, auditable credentials rather than a static local account.

Security Considerations

• Always use SSH version 2 — version 1 has known cryptographic weaknesses and should be explicitly disabled.
• Use an RSA key modulus of at least 2048 bits; smaller keys are considered weak by modern standards.
• Restrict SSH access with an ACL applied to the VTY lines:

R1(config)# access-list 10 permit 10.0.0.5
R1(config)# access-list 10 deny any log
R1(config)# line vty 0 4
R1(config-line)# access-class 10 in

• Disable Telnet entirely once SSH is confirmed working (transport input ssh, not transport input all).
• Consider public-key authentication instead of passwords for the highest level of security, especially for automation accounts.
• Regularly rotate the RSA host key if your organization’s policy requires periodic key rotation:

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

Best Practices

• Set a meaningful hostname and domain name before generating keys, since the key name is derived from both.
• Use login local with individual named accounts, or better yet, centralized AAA via TACACS+/RADIUS.
• Apply an access-class ACL to restrict which hosts can even attempt an SSH connection.
• Set ip ssh time-out and ip ssh authentication-retries to reasonable, restrictive values to slow down brute-force attempts.
• Log failed and successful login attempts using login on-failure log and login on-success log.
• Disable unused VTY lines with transport input none.

Performance Tuning

SSH’s encryption overhead is negligible on modern router hardware, but a few tuning considerations are still worth knowing:

• Use ip ssh version 2 explicitly rather than allowing both versions, since negotiating version 1 support adds unnecessary processing and security exposure.
• Limit the number of concurrent SSH sessions to what your team actually needs (line vty 0 15 for larger teams) to avoid exhausting the default five VTY lines during busy troubleshooting periods.
• On very high-throughput or CPU-constrained platforms, monitor show processes cpu sorted during heavy SSH session usage to confirm SSH processing is not becoming a bottleneck — in nearly all modern platforms, it will not be.

Troubleshooting and Common Configuration Mistakes

Mistake 1: RSA keys not generated SSH will not function without RSA keys. If you see % SSH is not enabled, this is almost always why:

R1(config)# crypto key generate rsa modulus 2048

Mistake 2: No domain name configured Key generation itself fails, or generates a key name that is difficult to manage, without a domain name set first via ip domain-name.

Mistake 3: Using transport input all in production This unintentionally leaves Telnet enabled alongside SSH, defeating the purpose of hardening remote access.

Mistake 4: Weak or default passwords Even with SSH’s encryption, a weak password can still be brute-forced or guessed; always enforce strong password policies alongside SSH.

Useful troubleshooting commands:

R1# show ip ssh
R1# show ssh
R1# debug ip ssh
R1# show crypto key mypubkey rsa

Frequently Asked Questions

Q: What port does SSH use? SSH uses TCP port 22 by default, though it can be changed for additional obscurity using ip ssh port <port> rotary <group> on supported platforms.

Q: Can I use SSH key-based authentication instead of passwords? Yes, Cisco IOS supports RSA public-key authentication for SSH; you configure the user’s public key under the username configuration.

Q: What is the minimum RSA key size for SSH version 2? Cisco requires a minimum of 768 bits for SSH v2, but 2048 bits is the practical minimum recommended for real security today.

Q: Why can’t I generate RSA keys on my router? This is usually because the hostname is still set to the default “Router” or the domain name has not been configured — both are prerequisites.

Q: Is SSH enough to secure my router by itself? No — SSH secures the transport of your management session, but you should still layer on ACL restrictions, strong passwords or AAA, and general device hardening.

Summary and Key Takeaways

SSH is the standard for secure remote management of Cisco routers, and configuring it properly involves setting a hostname and domain name, generating strong RSA keys, enabling SSH version 2, and locking VTY lines down to SSH-only access with local or centralized authentication. Pairing SSH with access-class ACLs, strong passwords, and ideally centralized AAA through TACACS+ gives you a genuinely secure remote management setup suitable for enterprise production environments. If you are still running Telnet anywhere in your network, migrating to SSH should be one of your very next priorities.

References

• Cisco IOS Secure Shell Configuration Guide: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/xe-16/sec-usr-ssh-xe-16-book.html
• Cisco SSH Version 2 Feature Documentation: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/15-mt/sec-usr-ssh-15-mt-book/sec-secure-shell-v2.html