Stackvora.tech

Cisco IOS: enable SSH access on a switch or router

Securing network device access is paramount, especially for remote administration. Telnet, due to its unencrypted nature, is unsuitable for modern…

Securing network device access is paramount, especially for remote administration. Telnet, due to its unencrypted nature, is unsuitable for modern networks. SSH (Secure Shell) provides a robust, encrypted alternative for managing Cisco IOS switches and routers. This article details the essential steps to configure SSH access, focusing on best practices and common considerations for network engineers and sysadmins.

The configuration process involves generating cryptographic keys, defining SSH parameters, creating local user accounts, and applying these settings to virtual terminal lines. We will cover prerequisites, step-by-step commands, and verification procedures for Cisco IOS devices running versions such as 15.x T or 16.x Universal images.

Prerequisites for SSH Configuration

Before configuring SSH, ensure the following conditions are met on your Cisco IOS device:

  • Hostname Configuration: A unique hostname must be set. This is crucial for distinguishing devices on the network and is a prerequisite for generating RSA keys.
  • IP Domain Name: An IP domain name must be configured. The combination of hostname and IP domain name forms the FQDN (Fully Qualified Domain Name), which is used by the crypto key generate rsa command to create the key pair.
  • Connectivity: The device must have IP reachability from the intended management workstations. While SSH itself doesn't require routing, basic IP configuration (IP address, subnet mask, default gateway) is necessary.
  • Cisco IOS Image: Ensure your IOS image supports cryptographic features. Most modern IOS images do, but older or "base" images might lack strong crypto. Look for images with "k9" in their filename (e.g., c2960s-universalk9-mz.152-4.E6.bin) indicating cryptographic support.

Step-by-Step SSH Configuration

1. Configure Hostname and IP Domain Name

These two parameters are essential for generating the RSA key pair.

SW1# configure terminal
SW1(config)# hostname SW1
SW1(config)# ip domain name stackvora.local
SW1(config)# end
SW1# show running-config | include hostname|ip domain-name
hostname SW1
ip domain name stackvora.local

The domain name does not need to be resolvable on the internet; it merely serves as a component of the FQDN for key generation.

2. Generate RSA Cryptographic Keys

SSH relies on RSA (Rivest-Shamir-Adleman) encryption for secure communication. The crypto key generate rsa command creates these keys. The modulus size determines the strength of the encryption; a 2048-bit modulus is a common recommendation for current security standards. Avoid using modulus sizes below 1024 bits for new deployments.

SW1# configure terminal
SW1(config)# crypto key generate rsa
The name for the keys will be: SW1.stackvora.local
Choose the size of the key modulus in the range of 360 to 4096 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.

How many bits in the modulus [512]: 2048
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 2 seconds)
SW1(config)# ip ssh version 2
SW1(config)# ip ssh authentication-retries 3
SW1(config)# ip ssh timeout 60
SW1(config)# end

The ip ssh version 2 command explicitly enables SSH version 2, which is more secure than SSHv1. SSHv1 should be avoided entirely due to known vulnerabilities. The ip ssh authentication-retries and ip ssh timeout commands define how many login attempts are allowed and how long a session can remain idle, respectively. Recommended values are 3 retries and 60 seconds timeout.

To view generated keys:

SW1# show crypto key mypubkey rsa
% Key pair was generated at: 09:27:01 UTC Nov 27 2023
Key name: SW1.stackvora.local
 Usage: General Purpose Key
 Key Data:
  30820122 02010100 C10... (output truncated for brevity)

If you need to regenerate keys (e.g., due to security concerns or changing modulus size), use crypto key zeroize rsa first to delete existing keys.

3. Create Local User Accounts

For authentication, it's best practice to use local user accounts on the device. While RADIUS or TACACS+ can be integrated, local accounts provide a fallback and are simpler for initial setup.

SW1# configure terminal
SW1(config)# username admin privilege 15 secret StrongP@ssw0rd!
SW1(config)# username nocuser privilege 1 secret NocUserP@ss
SW1(config)# end

Set a strong, complex password. The privilege 15 level grants full administrative access, while privilege 1 grants basic user access (read-only, minimal commands). Encrypt local passwords using service password-encryption if they are not already hashed (secret keyword hashes them).

4. Configure Virtual Terminal Lines (VTY)

VTY lines are used for remote access. By default, they often accept Telnet. To enforce SSH and control access, configure them as follows:

SW1# configure terminal
SW1(config)# line vty 0 15
SW1(config-line)# login local
SW1(config-line)# transport input ssh
SW1(config-line)# exec-timeout 10 0
SW1(config-line)# end
  • line vty 0 15: Configures VTY lines 0 through 15. The range might vary (e.g., 0 4 on older devices).
  • login local: Instructs the device to use local user accounts for authentication.
  • transport input ssh: This is critical. It restricts incoming connections on these VTY lines to SSH only, effectively disabling Telnet. You can also specify transport input all (allowing both, but not recommended), or transport input none (disabling all remote access).
  • exec-timeout 10 0: Sets the idle timeout for VTY sessions to 10 minutes and 0 seconds. This helps prevent unauthorized access to idle sessions.

5. (Optional but Recommended) Apply an ACL for Management Access

To further secure SSH access, create an Access Control List (ACL) that permits SSH only from specific management IP addresses or subnets. Apply this ACL to the VTY lines.

SW1# configure terminal
SW1(config)# ip access-list standard MANAGEMENT_SSH
SW1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
SW1(config-std-nacl)# deny any
SW1(config-std-nacl)# exit
SW1(config)# line vty 0 15
SW1(config-line)# access-class MANAGEMENT_SSH in
SW1(config-line)# end

This configuration only permits SSH connections from the 192.168.1.0/24 network. All other IP addresses attempting to connect will be denied by the implicit deny any at the end of the ACL or by the explicit deny any we added. Always test ACLs thoroughly in a lab environment before deploying to production.

Verification and Troubleshooting

Verification Commands

After configuration, verify SSH is operational:

  • show ip ssh: Displays the SSH server configuration, including version, authentication retries, and timeout. 
    SW1# show ip ssh
SSH Enabled - version 2.0
Authentication retries: 3           Auth timeout: 60 seconds
  • show users: Shows currently connected users and their connection type (e.g., VTY). 
    SW1# show users
    Line       User       Host             Idle       Location
*  0 con 0                idle             00:00:00
   1 vty 0     admin      192.168.1.100    00:00:05
  • show line vty: Displays configuration details for VTY lines, including transport input. 
    SW1# show line vty
   Line Typ     Tx/Rx      A/P Voa              Modem  AccsOut AccsIn   ForwDelay
*    0 VTY                -    -    -             -     -        -          -
   ...
   Line   TxRx A/P Modem  Accs FwdRef Location
   0 VTY  -    -    -             -              -    ssh
   ...
  • Attempt to connect via SSH from a management workstation using a client like OpenSSH (Linux/macOS) or PuTTY (Windows): 
    ssh admin@192.168.10.1

    And attempt to connect via Telnet to ensure it's blocked:

    telnet 192.168.10.1

    The Telnet connection should fail or be refused.

Common Pitfalls and Troubleshooting

  • "No RSA keypair defined": This error indicates that crypto key generate rsa either wasn't run, or the hostname/ip domain name changed after key generation. Re-generate the keys.
  • "Connection refused" or "Connection timed out":
    • Verify IP connectivity (ping from management host to switch).
    • Check if the VTY lines have transport input ssh configured.
    • Ensure the SSH server is enabled (show ip ssh).
    • If an ACL is applied (access-class in), verify that your source IP is permitted. Use show ip access-lists MANAGEMENT_SSH to check hit counts.
    • Check firewall rules on the management workstation or any intermediate network devices.
  • "Authentication failed":
    • Check the username and password used. Remember local accounts are case-sensitive.
    • Ensure login local is configured on the VTY lines.
    • If using AAA, verify the AAA configuration and connectivity to authentication servers.
  • Incompatible SSH versions: Ensure both client and server are using SSHv2. Cisco IOS ip ssh version 2 enforces this. If using an older client, it might only support SSHv1.
  • Missing Crypto Image: If crypto key generate rsa command is not found or fails with a cryptic error, the IOS image might not support strong cryptography. A "k9" image is usually required.
  • Modulus size too small: Some modern SSH clients might refuse to connect to servers using RSA keys smaller than 1024 bits. Always use 2048 bits or higher.

Always save your configuration using write memory or copy running-config startup-config after making changes to ensure they persist across reboots.

Back to the knowledge base · Ask the AI assistant