Describe network device management access (Telnet, SSH, HTTP, HTTPS, console, TACACS+/RADIUS, and cloud managed)

Every device in this chapter has to be configured somehow. Management access is the set of ways an administrator reaches a device’s configuration, and the exam wants you to know each method’s transport, port number, security properties, and typical use.

Console

The console port is a physical serial port on the front or back of every Cisco router and switch. You connect a laptop to it with a rollover cable (RJ-45 to DB-9 or USB) or a USB-to-mini-USB cable on newer devices, run a terminal program (PuTTY, SecureCRT, Tera Term), and set the serial parameters to 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control (9600 8N1). The console works with no IP address and no configuration at all, which makes it the method for initial setup, password recovery, and troubleshooting when the network is down. Its only disadvantage is that you must be physically present (or use a console server that provides remote access to many console ports). The related auxiliary (AUX) port, on routers, was historically for a dial-in modem.

Console line security:

R1(config)# line console 0
R1(config-line)# password C0ns0le!
R1(config-line)# login
! Or use local usernames instead of a shared password:
R1(config-line)# login local
R1(config-line)# exec-timeout 10 0
R1(config-line)# logging synchronous

Telnet

Telnet (TCP port 23) is the oldest remote CLI protocol. It gives you the same command line as the console over the network. Its fatal flaw is that everything, including passwords, is sent in clear text; anyone capturing packets on the path can read them. Telnet should be disabled on every modern device and used only in a lab. The Telnet client on a Cisco device is telnet 192.168.1.1.

Remote CLI sessions arrive on VTY lines (virtual teletype), traditionally line vty 0 4 (five simultaneous sessions) and on many platforms 0 15.

SSH

SSH (Secure Shell, TCP port 22) replaces Telnet with an encrypted, authenticated session. Use SSH version 2; version 1 has known weaknesses. SSH requires the device to have a hostname, a domain name, and an RSA key pair (the domain name and hostname are used to name the key). Domain 4 (objective 4.8) covers the full configuration; here is the summary because 2.8 expects you to recognize it:

R1(config)# hostname R1
R1(config)# ip domain-name example.com
! Generate the RSA key pair; 2048 bits or more
R1(config)# crypto key generate rsa modulus 2048
R1(config)# ip ssh version 2
R1(config)# username admin privilege 15 secret Str0ngPa55
R1(config)# line vty 0 15
! Allow only SSH (blocks Telnet) and require local username/password
R1(config-line)# transport input ssh
R1(config-line)# login local
R1(config-line)# exec-timeout 10 0

Verify with show ip ssh (version and timeouts) and show ssh (current sessions). From another Cisco device: ssh -l admin 192.168.1.1.

HTTP and HTTPS

Many devices offer a web GUI: switches have a small device manager, routers have a web setup page, and the WLC is managed almost entirely from a browser. HTTP uses TCP port 80 and, like Telnet, is unencrypted. HTTPS uses TCP port 443 and wraps the same web interface in TLS. Enable and disable them on IOS with:

R1(config)# no ip http server
R1(config)# ip http secure-server
R1(config)# ip http authentication local

Good practice is to disable HTTP and, if the GUI is not used at all, HTTPS as well; fewer open ports mean fewer attack surfaces. The WLC and Meraki dashboard use HTTPS by default.

Summary of protocols and ports

Centralized authentication: TACACS+ and RADIUS

With local usernames, every device has its own password database, and adding an administrator means touching every device. AAA (Authentication, Authorization, and Accounting) solves this by letting the device ask a central server: “here is a username and password; is this person allowed in, what may they do, and log what they did.” Two protocols carry that conversation between the network device (the AAA client) and the server.

The rule of thumb: TACACS+ for administrators, RADIUS for users. TACACS+ is chosen for device management because it can authorize each command individually (a junior admin may run show but not configure) and logs every command for accounting. RADIUS is chosen for network access because every vendor supports it and it integrates with 802.1X and WPA2/WPA3 Enterprise.

A minimal TACACS+ configuration for device login, with local fallback if the server is unreachable:

R1(config)# aaa new-model
! Define the server
R1(config)# tacacs server ISE1
R1(config-server-tacacs)# address ipv4 10.1.1.50
R1(config-server-tacacs)# key TacacsSecret123
R1(config-server-tacacs)# exit
! Put it in a group and use the group for login, falling back to local
R1(config)# aaa group server tacacs+ ISE-GROUP
R1(config-sg-tacacs+)# server name ISE1
R1(config-sg-tacacs+)# exit
R1(config)# aaa authentication login default group ISE-GROUP local
R1(config)# username fallback privilege 15 secret Backup!Pass

The RADIUS equivalent uses radius server ISE1, then address ipv4 10.1.1.50 auth-port 1812 acct-port 1813, key ..., and aaa group server radius. aaa new-model is the switch that turns AAA on; once it is entered, the lines default to login authentication default, so make sure a fallback method exists before you disconnect.

Cloud-managed access

In a cloud-managed model, of which Cisco Meraki is the standard example, you never SSH to a device at all. Each device makes an outbound HTTPS connection to the vendor’s cloud, and the administrator logs in to a web dashboard (over HTTPS) to configure, monitor, and update all devices in all sites from one place. The dashboard enforces two-factor authentication and role-based access. Devices receive their configuration from the cloud, so a replacement device just needs power and internet access. Advantages: zero-touch deployment, one console for many sites, automatic updates. Disadvantages: dependency on the vendor’s cloud and a subscription, and no traditional CLI (Meraki devices have only a very limited local status page).

Meraki devices are managed through a dashboard; in-between models like Cisco Catalyst Center (DNA Center) manage IOS-XE devices from a central controller using SSH, NETCONF, and RESTCONF under the hood, which Domain 6 covers.