Device Security & SSH

By Alec Gauldin, Principal Network Engineer · Updated July 2026

Every other topic on the CCNA assumes you can reach a device to configure it — and that the access layer isn't trivially spoofed. That is what device security covers: protecting the management plane (how you log in) and the access edge (what a host is allowed to do on a switchport). It sits in the Security Fundamentals area of the CCNA 200-301 blueprint, one of the more heavily weighted domains, though Cisco adjusts the exact percentages between blueprint revisions, so treat any single figure as approximate. The through-line is simple: stop sending credentials in cleartext, prove who is connecting, and don't trust a port just because a cable is plugged into it.

The first pillar is remote access with SSH. Telnet carries usernames and passwords in cleartext, so SSH replaces it. Enabling SSH is a short chain of prerequisites rather than one command: set a real hostname and an ip domain-name (the RSA key label is built from hostname.domain), generate keys with crypto key generate rsa, create a local username, force login local and transport input ssh on the VTY lines, and select ip ssh version 2. The 'Configure SSH on a Cisco Router or Switch' guide walks the full sequence; a companion guide shows that once SSH is up you connect from a Mac or Linux box with the built-in OpenSSH client (ssh user@device) — no PuTTY required, occasionally with a legacy key-exchange or cipher flag for older IOS.

The second pillar narrows who may even attempt a login. A standard ACL — which matches on source address only — applied to the VTY lines with access-class restricts management sessions to an approved subnet or jump host. This pairs naturally with SSH: encrypting the session protects the credentials, while the access-class controls where connections are allowed to originate. Together they harden the management plane end to end, which is why the SSH and VTY material is grouped here rather than buried in general ACL study.

The third pillar moves to the access edge, where port security controls which hosts a switchport will serve. You set a maximum number of MAC addresses and let the switch learn them as sticky entries, which are written into the running-config so they survive as a saved baseline. When the limit is exceeded, the violation mode decides what happens: protect silently drops offending traffic, restrict drops it while logging and incrementing a counter, and shutdown — the default — err-disables the port until you recover it. This is the CCNA's canonical defense against MAC flooding and rogue devices on user ports.

The fourth pillar defends the DHCP and ARP paths at Layer 2. DHCP snooping classifies ports as trusted or untrusted, permits DHCP server replies only on trusted uplinks, and builds a binding table of MAC-to-IP-to-port-to-VLAN mappings. Dynamic ARP Inspection then leans on that same binding table to validate ARP on untrusted ports, dropping spoofed replies that would otherwise enable man-in-the-middle attacks — so DAI effectively requires snooping to be in place first. The DHCP snooping and DAI guide covers enabling both per VLAN and trusting the correct uplinks.

Master it in three moves. First, understand the intent behind each feature — what threat it stops and which plane it protects — using this overview and the linked guides as your map. Second, keep the command cheat sheet open while you work so the SSH prerequisites, access-class placement, violation modes, and trust commands stay at your fingertips. Third, build and grade the hands-on labs and the device-security bundle: configuring these on live gear and getting instant pass/fail feedback is what turns recognition into recall for both the exam and the job.