Auto Draft

Securing the Management Plane on Cisco IOS-XE: SSH, VTY Hardening, Privilege Levels, and a Practical Checklist

Why the Management Plane Gets Compromised First

When a network device gets compromised, it’s rarely through a data-plane exploit. Most real-world breaches start at the management plane — an exposed Telnet port, an SNMP v1 community string left at “public,” an SSH session left open with a short timeout, or a VTY line with no access restriction. The management plane is the interface through which you control the device: SSH, NETCONF, REST APIs, SNMP, console, and auxiliary ports. Hardening it is the single most impactful security step you can take on an IOS-XE device.

This guide covers the full management plane hardening stack — SSH v2 configuration with modern ciphers, VTY access restrictions, privilege levels and parser views, disabling unnecessary services, logging, and Type 8/9 password hashing — with real IOS-XE CLI throughout and a copy-paste checklist at the end. For the data-plane counterpart — rate-limiting and policing traffic headed to the router’s CPU — the Control Plane Policing (CoPP) guide covers that in depth.

SSH v2 Hardening

If Telnet is still configured anywhere in your network, stop reading this and go fix that first. SSH v2 is non-negotiable. But SSH v2 alone isn’t enough — the default key size and cipher set on many older IOS-XE devices are weaker than they should be.

Generate a Strong RSA Key and Lock Down SSH

! Generate a 4096-bit RSA key pair (minimum 2048 for modern standards)
Router(config)# crypto key generate rsa modulus 4096

! Force SSH version 2 only
Router(config)# ip ssh version 2

! Set authentication timeout and retry limits
Router(config)# ip ssh time-out 60
Router(config)# ip ssh authentication-retries 3

! Restrict SSH to specific source subnets (replace with your management subnet)
Router(config)# ip access-list standard MGMT-ACCESS
Router(config-std-nacl)# permit 10.0.10.0 0.0.0.255
Router(config-std-nacl)# deny   any log
Router(config-std-nacl)# exit

Hardening SSH Ciphers and MACs (IOS-XE 16.12+)

On IOS-XE 16.12 and later, you can explicitly control which ciphers and MACs are offered during the SSH handshake. Drop legacy algorithms that no longer meet compliance requirements:

! Remove weak ciphers
Router(config)# ip ssh server algorithm encryption aes256-ctr aes192-ctr aes128-ctr

! Remove weak MACs (MD5-based MACs are a common audit finding)
Router(config)# ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512

! Optionally restrict KEX algorithms
Router(config)# ip ssh server algorithm kex diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 ecdh-sha2-nistp256

Verify what the device currently offers:

Router# show ip ssh server
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):
  ...
Server Encryption Algorithms  : aes256-ctr,aes192-ctr,aes128-ctr
Server MAC Algorithms         : hmac-sha2-256,hmac-sha2-512

VTY Line Hardening

VTY (Virtual Terminal) lines are where SSH sessions land. They need three specific hardening steps: restrict transport to SSH only, apply an inbound access-class, and set an idle timeout.

Router(config)# line vty 0 15
Router(config-line)# transport input ssh
Router(config-line)# login authentication VTY-AUTH
Router(config-line)# access-class MGMT-ACCESS in
Router(config-line)# exec-timeout 10 0
Router(config-line)# logging synchronous
Router(config-line)# exit

Breakdown of each command:

  • transport input ssh — disables Telnet, rlogin, and all other transports. SSH only.
  • login authentication VTY-AUTH — references an AAA method list. If you’re not using TACACS+/RADIUS, use login local at minimum, never login alone (which uses the line password, a single shared credential).
  • access-class MGMT-ACCESS in — applies the source IP restriction. A VTY session from outside your management subnet is dropped before authentication even starts.
  • exec-timeout 10 0 — terminates idle sessions after 10 minutes. The default on many devices is 10 minutes, but some older configs have it set to 0 (never), which means an unattended SSH session stays open indefinitely.

Console and AUX Lines

Router(config)# line console 0
Router(config-line)# login authentication CONSOLE-AUTH
Router(config-line)# exec-timeout 15 0
Router(config-line)# logging synchronous
Router(config-line)# exit

! Disable AUX line if not in use (most deployed devices never use it)
Router(config)# line aux 0
Router(config-line)# transport input none
Router(config-line)# no exec
Router(config-line)# exit

Password Hashing: Type 8 and Type 9

IOS-XE supports several password types. Type 7 (XOR-based, reversible) and Type 5 (MD5) are both considered broken by modern standards. Use Type 8 (PBKDF2-SHA256) or Type 9 (scrypt) for all local user passwords:

! Type 9 (scrypt) - strongest, preferred on IOS-XE 16.9+
Router(config)# username admin privilege 15 algorithm-type scrypt secret Str0ng!Pass#2026
Router(config)# username noc    privilege 7  algorithm-type scrypt secret N0cTeam!Pass#2026

! Enable password - also use Type 9
Router(config)# enable algorithm-type scrypt secret Enab!eStr0ng#2026

! Enforce minimum password requirements
Router(config)# security passwords min-length 12

Verify what hashing type is stored in the config — look at the number after “secret”:

Router# show running-config | include username
username admin privilege 15 secret 9 $9$KVd0KVd0iBV8iBV8...
username noc   privilege 7  secret 9 $9$Nl8UNl8U5kEI5kEI...

A $9$ prefix confirms scrypt. $8$ is PBKDF2. If you see $1$ (MD5) or no prefix (Type 7/0), migrate immediately. The service password-encryption command only applies Type 7 to line passwords and pre-shared keys — it doesn’t affect user secret hashes and provides minimal real security.

Privilege Levels and Parser Views

By default, IOS-XE has two functional privilege levels: 1 (user EXEC) and 15 (privileged EXEC). Most shops hand out level 15 to everyone who needs SSH access. A better approach uses either custom privilege levels or parser views to give NOC engineers exactly what they need and nothing more.

Custom Privilege Levels

! Give privilege 7 access to show commands and interface resets only
Router(config)# privilege exec level 7 show
Router(config)# privilege exec level 7 clear interface
Router(config)# privilege exec level 7 ping
Router(config)# privilege exec level 7 traceroute

! Deny level 7 users from reaching config mode
! (config mode defaults to level 15; no action needed — just don't grant it)

Parser Views (Role-Based CLI)

Parser views are more granular than privilege levels — they define an explicit set of commands per role rather than a privilege ceiling:

! Enable AAA (required for parser views)
Router(config)# aaa new-model

! Create a NOC view — show and clear only
Router(config)# parser view NOC-VIEW
Router(config-view)# secret 9 $9$NOCViewSecr3t...
Router(config-view)# commands exec include show
Router(config-view)# commands exec include ping
Router(config-view)# commands exec include traceroute
Router(config-view)# commands exec include clear interface
Router(config-view)# exit

! Assign a user to a view
Router(config)# username nocuser privilege 15 algorithm-type scrypt secret Pass#2026
! Then the user enters: enable view NOC-VIEW (and provides view password)

Once inside a view, the user can only tab-complete and execute the commands explicitly included in that view. Any attempt to run configure terminal or show running-config returns “% Invalid input.”

Disable Unnecessary Services

Every enabled service is a potential attack surface. Most should be off by default on a hardened IOS-XE device:

! Disable HTTP/HTTPS management server (use SSH instead)
Router(config)# no ip http server
Router(config)# no ip http secure-server

! Disable CDP on WAN/untrusted interfaces (keep on internal infrastructure links)
Router(config)# interface GigabitEthernet0/0/0
Router(config-if)# no cdp enable
Router(config-if)# exit

! Globally disable LLDP if not needed (or restrict per-interface)
Router(config)# no lldp run

! Disable IP source routing
Router(config)# no ip source-route

! Disable proxy ARP on all interfaces (unless explicitly needed)
Router(config)# interface GigabitEthernet0/0/0
Router(config-if)# no ip proxy-arp

! Disable ICMP redirects and unreachables on transit interfaces
Router(config-if)# no ip redirects
Router(config-if)# no ip unreachables

! Disable TCP/UDP small servers (echo, chargen, discard)
Router(config)# no service tcp-small-servers
Router(config)# no service udp-small-servers

! Disable finger and bootp
Router(config)# no service finger
Router(config)# no ip bootp server

Logging and Syslog

Logs you never see are logs that never stop an attack. Configure remote syslog with at minimum informational level, and enable timestamped local buffering for immediate troubleshooting:

! Timestamps on all log messages
Router(config)# service timestamps log datetime msec localtime show-timezone

! Local buffer (keep last 100,000 lines of informational logs)
Router(config)# logging buffered 100000 informational

! Remote syslog server
Router(config)# logging host 10.0.10.50
Router(config)# logging trap informational

! Log all login attempts (both successful and failed)
Router(config)# login on-failure log
Router(config)# login on-success log

! Secure logging source (always originate from loopback, not a physical interface)
Router(config)# logging source-interface Loopback0

Use the loopback as the logging source — it’s always up, and it gives your SIEM a consistent source IP regardless of which physical interface the router uses to reach the syslog server.

Securing NETCONF and RESTCONF

Modern IOS-XE devices increasingly use NETCONF (port 830) and RESTCONF (port 443) for programmatic configuration via YANG models. If your automation pipeline uses these protocols, they need the same hardening attention as SSH.

! Enable NETCONF over SSH (preferred — rides on existing SSH hardening)
Router(config)# netconf-yang

! RESTCONF — only enable if your automation requires it
Router(config)# restconf

! Restrict NETCONF access to the management VRF
Router(config)# netconf-yang ssh ipv4 access-list MGMT-ACCESS

! Apply a dedicated RESTCONF access list
Router(config)# ip http access-class MGMT-ACCESS

Verify NETCONF is listening and check which users have NETCONF privilege:

Router# show netconf-yang sessions
Number of NETCONF sessions open: 1

session-id  transport    username   source-host      login-time
----------  -----------  ---------  ---------------  --------------------
1           netconf-ssh  admin      10.0.10.15       2026-10-27T09:30:00Z

Router# show netconf-yang statistics
Netconf-yang: enabled
  transport: netconf-ssh
  listening on port: 830
  access restriction: MGMT-ACCESS

If you’re not using NETCONF or RESTCONF, disable them explicitly with no netconf-yang and no restconf. A protocol you don’t use that’s left enabled is an open door. For RESTCONF specifically, confirm the HTTP secure-server is disabled unless RESTCONF explicitly requires it:

! Only enable HTTPS if RESTCONF is actively in use
Router(config)# ip http secure-server
Router(config)# ip http secure-port 443
Router(config)# ip http tls-version TLSv1.2
Router(config)# no ip http server   ! HTTP (plain) always off

Verification: Checking Your Hardening

! Confirm SSH settings
Router# show ip ssh
SSH Enabled - version 2.0
Authentication timeout: 60 secs; Authentication retries: 3

! Check which services are listening
Router# show control-plane host open-ports
Active internet connections (servers and established)
Prot    Local Address           Foreign Address         Service    State
tcp         *:22                      *:0              SSH-Server  LISTEN
tcp         *:514                     *:0              Syslog      LISTEN

! Verify no Telnet listeners remain
Router# show line | include Telnet
(no output expected)

! Confirm VTY access-class is applied
Router# show line vty 0 15 | include access
   Allowed input transports are SSH.
   Timeout: 10 min 0 sec
   access-class MGMT-ACCESS, in

! Check for any Type 5 or clear-text passwords that need migration
Router# show running-config | include secret|password
(scan output for $1$ or $0$ — migrate any found)

Management Plane Hardening Checklist

Use this as a quick audit checklist against any IOS-XE device:

Item Command to Check Expected State
SSH v2 only show ip ssh Version 2.0
RSA key ≥ 2048 bits show crypto key mypubkey rsa 2048 or 4096
Telnet disabled on VTY show running-config | section line vty transport input ssh
VTY access-class applied show line vty 0 15 access-class present
VTY idle timeout ≤ 15 min show line vty 0 15 Timeout ≤ 15:00
Password hashing Type 8/9 show running-config | include secret $8$ or $9$ prefix
HTTP server disabled show ip http server status HTTP server: disabled
CDP off on WAN interfaces show cdp interface WAN int not listed
Remote syslog configured show logging Logging to syslog host
Login logging enabled show running-config | include login on on-failure log, on-success log

Putting It All Together

Management plane hardening isn’t a one-time task — it’s a baseline configuration that should be templated into your provisioning workflow and audited regularly. The checklist above translates directly into a Cisco EEM script or Ansible playbook that can verify compliance across your entire fleet. For network-wide enforcement, a Cisco EEM script can alert when someone enables Telnet or weakens SSH settings. For the complementary data-plane hardening — ensuring the router CPU isn’t overwhelmed by crafted packets — combine these settings with a proper CoPP policy.

The underlying principle is simple: the management plane is the highest-privilege access path into your network infrastructure. Treat it accordingly. Lock down the transport, restrict the source, enforce strong authentication, eliminate legacy services, and log everything. An attacker who can’t reach your SSH port and can’t brute-force your hashed credentials has nowhere to go — and that’s exactly where you want them.

For context on how IOS-XE fits into Cisco’s broader software platform strategy, the IOS vs IOS-XE vs IOS-XR comparison is a useful reference when applying these settings across mixed-platform environments.

Enjoying this post?

Get more guides like this delivered straight to your inbox. No spam, just tech and trails.