RSA Key Too Small for SSHv2 — SSH Connection Refused
Presenting Symptom
SSH connection to the Cisco router is refused with the error 'Unable to negotiate with <IP> port 22: no matching host key type found. Their offer: ssh-rsa'.
Network Context
A small branch office with a Cisco 4321 router running IOS XE 16.9. The router is configured for SSH access but recently the crypto key was regenerated. The network engineer is trying to SSH from a modern client (e.g., OpenSSH 8.8+) that requires host keys of at least 2048 bits for SSHv2.
Diagnostic Steps
Check SSH server configuration
show ip sshSSH Enabled - version 2.0 Authentication timeout: 120 secs; Authentication retries: 3 Minimum expected Diffie-Hellman key size: 1024 bits IOS Keys in SECSH format(ssh-rsa, ssh-dss) Router#
Verify SSH version is 2.0. The output shows SSH is enabled with version 2.0. Note the key types listed: ssh-rsa and ssh-dss. If the key size is too small, it may not be listed or may show a warning.
Check the RSA key pair details
show crypto key mypubkey rsaKey name: Router.cisco.com Usage: General Purpose Key Key is not exportable. Key Data: 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A 020100 ... (hex output truncated) Key size: 1024 bits Key type: RSA Key storage: private Key hash: ...
Look for the key size. If it shows 1024 bits or less, that is the root cause. SSHv2 requires at least 2048-bit RSA keys. The output above shows 1024 bits, which is too small.
Check SSH debug logs for negotiation details
debug ip sshSSH: host key: hostkey size 1024 SSH: send SSH2_MSG_KEXINIT SSH: SSH2_MSG_KEXINIT received SSH: kex: client->server cipher: aes256-ctr SSH: kex: server->client cipher: aes256-ctr SSH: kex: client->server mac: hmac-sha2-256 SSH: kex: server->client mac: hmac-sha2-256 SSH: kex: client->server compression: none SSH: kex: server->client compression: none SSH: kex: host key: ssh-rsa SSH: kex: host key size 1024 SSH2: kex_parse_kexinit: host key algorithm: ssh-rsa SSH2: kex_parse_kexinit: host key size 1024 SSH: SSH2_MSG_KEXINIT sent SSH: SSH2_MSG_KEXINIT received SSH: kex: client->server cipher: aes256-ctr SSH: kex: server->client cipher: aes256-ctr SSH: kex: client->server mac: hmac-sha2-256 SSH: kex: server->client mac: hmac-sha2-256 SSH: kex: client->server compression: none SSH: kex: server->client compression: none SSH: kex: host key: ssh-rsa SSH: kex: host key size 1024 SSH2: kex_parse_kexinit: host key algorithm: ssh-rsa SSH2: kex_parse_kexinit: host key size 1024 %SSH-3-NO_MATCH: No matching host key type found. Client offers: rsa-sha2-256,rsa-sha2-512,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
The debug output confirms the router offers an ssh-rsa host key of only 1024 bits. The client (modern OpenSSH) requires at least 2048-bit RSA keys or other algorithms like ecdsa-sha2-nistp256. The 'NO_MATCH' error indicates the client rejects the small key.
Verify the current crypto key configuration
show running-config | include crypto keycrypto key generate rsa general-keys modulus 1024
The running config shows the RSA key was generated with modulus 1024. This is the misconfiguration. The key must be regenerated with modulus 2048 or higher.
Root Cause
The RSA host key was generated with a modulus of 1024 bits, which is too small for SSHv2. Modern SSH clients (e.g., OpenSSH 8.8+) require at least 2048-bit RSA keys for the ssh-rsa algorithm, or they support other key types like ecdsa-sha2-nistp256. The router's 1024-bit key is rejected, causing the SSH connection to be refused.
Resolution
Verification
1. Verify the new key size: Router# show crypto key mypubkey rsa Output should show 'Key size: 2048 bits' or higher. 2. Verify SSH server status: Router# show ip ssh Output should show 'SSH Enabled - version 2.0' and 'Minimum expected Diffie-Hellman key size: 1024 bits' (or higher). 3. Attempt an SSH connection from the client: Client$ ssh admin@<router-ip> Should connect successfully without host key errors.
Prevention
1. Always generate RSA keys with modulus 2048 or higher when configuring SSH on Cisco devices. 2. Consider using ECDSA keys (e.g., crypto key generate ecdsa keysize 256) for better security and compatibility with modern clients. 3. Regularly review and update cryptographic keys as part of security best practices.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario may appear as a troubleshooting question where the candidate must identify why SSH connections fail. The exam tests knowledge of SSH configuration, RSA key generation, and the requirement for minimum key sizes (2048 bits) for SSHv2. Candidates must know the commands 'show ip ssh', 'show crypto key mypubkey rsa', and 'crypto key generate rsa general-keys modulus <size>'.
Exam Tips
Remember that SSHv2 requires RSA keys of at least 2048 bits; 1024-bit keys are rejected by modern clients.
The command 'crypto key zeroize rsa' is used to delete existing RSA keys before regenerating.
Know that 'show crypto key mypubkey rsa' displays the key size; look for 'Key size: 2048' or higher.
Commands Used in This Scenario
crypto key generate rsa modulus [bits]
Generates an RSA key pair for SSH, encryption, or digital signatures on a Cisco IOS device, typically used to enable secure management access.
show ip ssh
Displays the status and configuration of SSH server on the Cisco IOS device, used to verify SSH is enabled and check connection details.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions