The management plane is how you reach and control your devices: SSH sessions, SNMP polls, NTP syncs, the VTY lines an engineer logs into. It is also the softest target on the box, because it is the one part of the router that will happily talk back to anyone who connects. Every device left with default SSH, no VTY restrictions, and no brute-force protection is a device waiting for an unattended login attempt to succeed.
This article hardens the management plane on Cisco IOS XE with real captures of a modern, secured configuration. It extends the Infrastructure Security cluster guide and complements AAA (who gets in) and CoPP (protecting the CPU that serves these sessions).
SSH, Done Right for 2026
SSH is table stakes, but "configured SSH" and "hardened SSH" are different things. Start with a strong host key. On modern IOS XE this is not a suggestion; the software enforces it:
R1(config)# crypto key generate rsa modulus 2048 label PINGLABZ.KEYS
Please create an RSA key of atleast 3072 bits or an EC key of atleast 384 bits to enable SSH server functionalityThe router rejects a 2048-bit key outright. That is a meaningful change: older guidance said 2048 was fine, and IOS XE 17.x now demands 3072-bit RSA (or a 384-bit elliptic-curve key) before it will even enable the SSH server. Generate a compliant key:
R1# crypto key generate rsa modulus 3072 label PINGLABZ.KEYS
% The key modulus size is 3072 bits
% Generating crypto RSA keys in background ...Then enforce version 2 and sane timeouts:
R1(config)# ip ssh version 2
R1(config)# ip ssh time-out 60
R1(config)# ip ssh authentication-retries 3Verify what the box is actually offering, and this output is worth reading in full because it tells you your real cryptographic posture:
R1#show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 60 secs; Authentication retries: 3
KEX Algorithms:curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,...,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512
Encryption Algorithms:chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-gcm,aes256-gcm,aes128-ctr,aes192-ctr,aes256-ctr
MAC Algorithms:hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
Minimum expected Diffie Hellman key size : 2048 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): PINGLABZ.KEYS
Modulus Size : 3072 bitsNote what modern IOS XE offers by default: curve25519 key exchange, ChaCha20-Poly1305 and AES-GCM ciphers, and ETM (encrypt-then-MAC) integrity. These are current, strong algorithms. Older code offered weak ciphers (3DES, arcfour) and weak KEX (diffie-hellman-group1-sha1) that you had to manually disable. On 17.x the defaults are good; your job is to confirm them and, in high-security environments, to explicitly restrict to only the strongest with ip ssh server algorithm commands.
Restrict Who Can Even Connect
Strong SSH still answers the door for the entire internet if you let it. A VTY access-class limits which source addresses can attempt to connect at all, so a brute-force from an unexpected network never even reaches the authentication stage:
R1(config)# ip access-list standard MGMT-ACCESS
R1(config-std-nacl)# permit 192.168.99.0 0.0.0.255
R1(config-std-nacl)# deny any log
!
R1(config)# line vty 0 4
R1(config-line)# access-class MGMT-ACCESS in
R1(config-line)# exec-timeout 5 0
R1(config-line)# transport input sshThree controls in that block, each important:
deny any log records every rejected attempt.The management ACL is the same idea as restricting your automation host in the API security article: define where management can originate, and reject everything else at the earliest possible point.
Brute-Force Protection: login block-for
Even with a VTY ACL, an attacker inside the permitted range (or a compromised management host) can hammer the login. login block-for detects repeated failures and locks logins entirely for a cooldown period:
R1(config)# login block-for 120 attempts 4 within 60
R1(config)# login delay 2
R1(config)# login on-failure log
R1(config)# login on-success logRead as: if 4 login failures occur within 60 seconds, disable all logins for 120 seconds. login delay 2 forces a 2-second gap between attempts, which alone defeats high-speed guessing. And on-failure/on-success log means every login, good or bad, is recorded, which is your early warning of an attack in progress.
The router exposes its current state, which is genuinely useful during an incident:
R1#show login
A login delay of 2 seconds is applied.
All successful login is logged.
All failed login is logged.
Router enabled to watch for login Attacks.
If more than 4 login failures occur in 60 seconds or less,
logins will be disabled for 120 seconds.
Router presently in Normal-Mode.
Current Watch Window remaining time 29 seconds.
Present login failure count 0."Normal-Mode" means no attack is currently detected. Under a brute-force this flips to "Quiet-Mode" and logins are refused until the cooldown expires. You can even exempt your management subnet from Quiet-Mode with a login quiet-mode access-class, so a real attack from elsewhere cannot lock you out while it is being blocked, a nice touch that avoids the self-inflicted lockout.
SNMP: v3 Only
SNMP is a management-plane protocol and a classic exposure. SNMPv1 and v2c authenticate with a community string sent in cleartext, which is to say they barely authenticate at all. A sniffed public or private community is full read (or write) access. On any device that matters, use v3 exclusively:
R1(config)# snmp-server group SECURE-GRP v3 priv
R1(config)# snmp-server user snmpadmin SECURE-GRP v3 auth sha AuthPass123! priv aes 128 PrivPass123!SNMPv3 with auth ... priv gives you authentication (SHA) and encryption (AES) of the SNMP payload. Combine it with an ACL restricting which NMS can poll, and remove any lingering v2c communities. The SNMP article covers the version differences in depth; from a hardening standpoint the rule is one line: no v2c on production devices.
The Rest of the Checklist
- Encrypt stored passwords.
service password-encryptionat minimum, andenable secret/username ... secret(which use strong hashing) rather thanpassword. - Authenticate NTP. An attacker who can move your clock can break certificate validation and defeat time-based ACLs.
ntp authenticateplus trusted keys. (See NTP.) - Disable unused services. No HTTP server if you use HTTPS/RESTCONF; no CDP on untrusted edges; no unused small servers.
- Banner. A legal login banner (
banner login) is not security, but it is often a legal prerequisite for prosecuting unauthorized access. - Console and AUX. The management plane is not just VTY. Secure the console with a password and exec-timeout, and disable the AUX port outright.
- AAA for logins. Point VTY authentication at AAA with a local fallback, so access is centrally controlled and audited.
FAQ
Why does IOS XE reject my 2048-bit SSH key?
Modern IOS XE (17.x) enforces a minimum of 3072-bit RSA (or 384-bit EC) for the SSH server. Older 2048-bit guidance is deprecated. Generate a 3072-bit key.
Do I still need to disable weak SSH ciphers manually?
On 17.x the defaults are already strong (curve25519, AES-GCM, ChaCha20). In high-security environments you can still explicitly restrict to only the strongest with ip ssh server algorithm encryption/mac/kex, but the era of shipping with 3DES and SHA1 enabled by default is over.
Will login block-for lock me out?
It can, which is why you can exempt your management subnet with login quiet-mode access-class. Then an attack from elsewhere triggers Quiet-Mode without blocking your legitimate source.
Is a VTY ACL enough on its own?
No. It limits where connections can come from, but an attacker inside that range still needs stopping, hence login block-for, strong AAA, and SSH-only transport layered on top.
What is the single highest-impact line here?
transport input ssh on the VTY lines. It disables Telnet, closing the most common and most serious legacy management-plane exposure in one command.
Key Takeaways
- Modern IOS XE enforces 3072-bit RSA (or 384-bit EC) SSH keys and ships with strong defaults (curve25519, AES-GCM, ChaCha20). Confirm them with
show ip ssh. - Restrict the VTYs: access-class to limit source, exec-timeout to close idle sessions, and transport input ssh to kill Telnet.
- login block-for plus
login delaydefeats brute-force, andshow loginreports Normal vs Quiet mode live. Exempt your own subnet to avoid self-lockout. - SNMP v3 only (auth + priv). v2c community strings are cleartext and disqualifying on production devices.
- Round it out: encrypted/hashed passwords, authenticated NTP, disabled unused services, secured console/AUX, and AAA with a local fallback.
- The single biggest quick win is
transport input ssh: disabling Telnet closes the classic management exposure in one line.
Next: AAA for centralized login control, or the Infrastructure Security cluster guide.
