SSH vs Telnet – Securing Remote Access

1. Remote Access to Network Devices — Why It Matters

Network administrators must be able to manage routers and switches remotely — applying configuration changes, monitoring status, and troubleshooting faults — without requiring physical access to every device. Two protocols have historically been used for this: Telnet (TCP port 23) and SSH — Secure Shell (TCP port 22).

The choice between them has profound security implications. Telnet transmits everything — usernames, passwords, configuration commands, and all session data — in plaintext. Anyone with the ability to capture packets on the path between the administrator and the device (a man-in-the-middle attacker, a rogue employee, or a compromised network device) can read every keystroke. SSH eliminates this risk by encrypting the entire session using public-key cryptography.

Feature	Telnet	SSH
TCP port	23	22
Encryption	None — plaintext transmission	Full session encryption (AES, 3DES, ChaCha20)
Authentication	Username/password sent in cleartext	Password or public-key authentication, encrypted
Integrity checking	None — data can be tampered in transit	HMAC ensures data integrity — tampering is detectable
Host verification	None — no way to confirm device identity	Server presents RSA/ECDSA host key — client can verify
Man-in-the-middle risk	High — attacker can read and inject session data	Low — encrypted + host-key verification prevents MITM
Recommended for production	No — considered insecure; deprecated in most networks	Yes — industry standard for remote device management
RFC	RFC 854	RFC 4251–4254 (SSHv2)

2. Why Telnet Is Insecure — The Cleartext Problem

Telnet was designed in 1969 when the Internet was a small, trusted academic network. Security was not a design consideration. Every byte exchanged in a Telnet session — including the login password, enable password, and every configuration command typed — travels across the network as unencrypted ASCII text.

Telnet Packet Capture — What an Attacker Sees

  An attacker running Wireshark (or tcpdump) on the same network segment
  captures a Telnet session to a Cisco router:

  Packet captures (raw Telnet data, plaintext):

  → "U" "s" "e" "r" "n" "a" "m" "e" ":" " " "a" "d" "m" "i" "n"
  → "P" "a" "s" "s" "w" "o" "r" "d" ":" " " "C" "i" "s" "c" "o" "1" "2" "3"
  → "R" "o" "u" "t" "e" "r" "#"
  → "e" "n" "a" "b" "l" "e"
  → "P" "a" "s" "s" "w" "o" "r" "d" ":" " " "E" "n" "a" "b" "l" "e" "P" "w"
  → "c" "o" "n" "f" " " "t"
  → "i" "n" "t" " " "g" "0" "/" "0"
  → "i" "p" " " "a" "d" "d" " " "1" "9" "2" "." "1" "6" "8" "." "1" "." "1"

  The attacker now has:
  - Username:     admin
  - User password: Cisco123
  - Enable password: EnablePw
  - Every command typed during the session
  - Full network topology from the configuration

  All of this from a single packet capture — zero effort required.

Attack Vectors for Telnet

Attack Type	How Telnet Enables It
Passive eavesdropping	Any device on the path (hub, compromised switch, SPAN port) can capture the full Telnet session including all credentials
Man-in-the-middle (MITM)	Attacker intercepts and relays Telnet session — can read and modify commands in real time without either party knowing
Credential replay	Captured username/password can be replayed to log in to the same or other devices that share credentials
Session hijacking	Attacker injects commands into an active Telnet session by predicting TCP sequence numbers

Telnet in modern networks: Telnet should never be used for managing production network devices. It may be acceptable only in completely isolated lab environments with no access to production networks or the Internet. Many security frameworks (CIS Benchmarks, NIST SP 800-115) explicitly require disabling Telnet on all network infrastructure.

3. How SSH Secures the Session

SSH (Secure Shell) uses a combination of asymmetric (public-key) cryptography for initial key exchange and authentication, and symmetric cryptography for bulk session encryption. The result is a channel where all data — including credentials — is encrypted and integrity-protected from end to end.

SSH Session Establishment — Step by Step

  SSH connection setup between admin workstation and Cisco router:

  Step 1 — TCP connection established (port 22)
  Admin ──[TCP SYN]──► Router :22
  Admin ◄─[TCP SYN-ACK]── Router
  Admin ──[TCP ACK]──► Router

  Step 2 — Protocol version negotiation
  Admin ◄──► Router: "SSH-2.0" exchanged — both agree on SSHv2

  Step 3 — Algorithm negotiation (key exchange, encryption, MAC, compression)
  Admin ◄──► Router: exchange supported cipher/MAC lists
  Both agree on: key exchange = diffie-hellman-group14-sha256
                 encryption   = aes256-ctr
                 MAC          = hmac-sha2-256

  Step 4 — Key exchange (Diffie-Hellman)
  Admin and Router independently compute a shared secret
  WITHOUT transmitting the secret across the network.
  Result: both sides have the same symmetric session key
          that no eavesdropper can derive from the exchange.

  Step 5 — Router host key verification
  Router sends its RSA/ECDSA public host key to the admin.
  Admin workstation checks against known_hosts:
  - First connection: "The authenticity of host cannot be established.
    Fingerprint: SHA256:xxxx. Are you sure you want to continue? yes"
  - Subsequent connections: fingerprint is verified automatically.
  If fingerprint changes unexpectedly → MITM warning.

  Step 6 — User authentication (over the encrypted channel)
  Admin sends username and password (or public key) — ALL ENCRYPTED.
  Even if captured, the encrypted credential is useless to an attacker.

  Step 7 — Session active
  All subsequent data (commands, output) is encrypted + integrity-checked.
  An attacker capturing packets sees only random ciphertext.

SSH v1 vs SSH v2

Feature	SSH Version 1	SSH Version 2
Key exchange	RSA only — known vulnerabilities	Diffie-Hellman, ECDH — more secure
Integrity	CRC-32 — susceptible to insertion attacks	HMAC-SHA — cryptographically strong
Authentication methods	Password, RSA host-based	Password, public-key, GSSAPI, keyboard-interactive
Known vulnerabilities	Session insertion, man-in-the-middle, CRC-32 weakness	No known fundamental protocol weaknesses
Recommended	No — deprecated; disable on all devices	Yes — always use SSHv2 in production

CCNA exam requirement: Always configure ip ssh version 2 on Cisco devices. SSH v1 has known cryptographic weaknesses and should never be used. If a question asks about SSH configuration, assume SSHv2 is required unless stated otherwise.

4. SSH Configuration Prerequisites on Cisco IOS

Before SSH can be enabled on a Cisco router or switch, four prerequisites must be met. Missing any one of them prevents SSH from functioning.

Prerequisite	Command	Why Required
IP domain name	`ip domain-name <name>`	Used together with the hostname to generate the RSA key pair. The fully qualified domain name (hostname + domain) forms the key label. Without a domain name, the `crypto key generate rsa` command is rejected.
Hostname (not default)	`hostname <name>`	Must not be the default "Router" or "Switch" — the hostname is part of the RSA key label. A meaningful hostname is also required by best practice.
RSA key pair	`crypto key generate rsa modulus <bits>`	SSH uses RSA asymmetric keys for host authentication and key exchange. The key pair must exist before SSH sessions can be established. Minimum 768 bits for SSHv2; recommended 2048 bits.
Local username and password	`username <name> privilege <level> secret <pass>`	SSH requires username-based authentication (`login local`). A VTY password alone (`password` + `login`) is not sufficient for SSH — a local username database or AAA server is required.

  Prerequisite check — what happens without each:

  Missing ip domain-name:
  Router(config)# crypto key generate rsa
  % Please define a domain-name first.

  Missing hostname (still "Router"):
  Router(config)# crypto key generate rsa
  Key will be generated using the label "Router.domain.com"
  (works but key is labelled with generic hostname — not best practice)

  Missing RSA key:
  Router# show ip ssh
  SSH Disabled - version 2.0
  %Please create RSA keys (of at least 768 bits size) to enable SSH v2.

  Missing local username (only vty password set):
  SSH session attempt:
  % No username set. SSH requires that a local username be configured.

5. Full SSH v2 Configuration — Step by Step

The following is the complete SSH version 2 configuration for a Cisco IOS router or switch, including all best-practice hardening options.

Step 1 — Set Hostname and Domain Name

  Router(config)# hostname R1
  R1(config)# ip domain-name netstuts.com

Step 2 — Create Local User Account

  ! privilege 15 = full administrative access (level 0-15; 15 = highest)
  ! secret = stores password as SHA-256 hash (not reversible)
  ! Never use "password" instead of "secret" — "password" stores in MD5 or cleartext

  R1(config)# username admin privilege 15 secret Str0ngP@ssw0rd

  ! For multiple privilege levels (separation of duties):
  R1(config)# username netops privilege 10 secret Oper@t0rPw
  R1(config)# username readonly privilege 1 secret V1ewOnly!

Step 3 — Generate RSA Key Pair

  R1(config)# crypto key generate rsa modulus 2048
  The name for the keys will be: R1.netstuts.com
  % Generating 2048 bit RSA keys, keys will be non-exportable...
  [OK] (elapsed time was 3 seconds)

  Key size guidelines:
  768 bits  → minimum for SSHv2 (weak — do not use in production)
  1024 bits → acceptable but being phased out
  2048 bits → recommended minimum for production
  4096 bits → high-security environments

  ! Verify the key was generated:
  R1# show crypto key mypubkey rsa
  % Key pair was generated at: 12:00:00 UTC Jan 1 2025
    Key name: R1.netstuts.com
    Key type: RSA KEYS
    Storage Device: not specified
    Usage: General Purpose Key
    Key is not exportable.
    Key Data:
      30820122 ... (public key in hex)

Step 4 — Specify SSH Version 2

  R1(config)# ip ssh version 2

  ! Verify:
  R1# show ip ssh
  SSH Enabled - version 2.0
  Authentication timeout: 120 secs; Authentication retries: 3

Step 5 — Configure VTY Lines for SSH Only

  R1(config)# line vty 0 4
  R1(config-line)# login local                  ! use local username database
  R1(config-line)# transport input ssh          ! ONLY SSH — Telnet is rejected
  R1(config-line)# exec-timeout 10 0            ! disconnect idle sessions after 10 minutes

  ! "transport input ssh" replaces the default "transport input all" which
  ! allows both Telnet and SSH. With "ssh" only, any Telnet attempt to port 23
  ! receives a "connection refused" response.

  ! For routers with more than 5 VTY lines (supports up to 15 simultaneous sessions):
  R1(config)# line vty 5 15
  R1(config-line)# login local
  R1(config-line)# transport input ssh
  R1(config-line)# exec-timeout 10 0

Step 6 — Enable Password Encryption (Global)

  ! Encrypt all plaintext passwords currently in running-config (Type 7 — Vigenere):
  R1(config)# service password-encryption

  ! Note: "service password-encryption" uses weak Type 7 encoding — easily reversed.
  ! Always use "secret" instead of "password" for user accounts (uses Type 9 / SHA-256).
  ! "service password-encryption" protects against casual shoulder-surfing but is
  ! NOT a substitute for strong hashing algorithms.

Step 7 — Set SSH Timeout and Retry Parameters

  ! Authentication timeout: maximum seconds to complete login (default 120):
  R1(config)# ip ssh time-out 60

  ! Maximum failed authentication attempts before disconnecting (default 3):
  R1(config)# ip ssh authentication-retries 3

  ! These settings limit brute-force login attempts.
  ! Combined with login block-for (see Section 8), they provide strong protection.

Complete Configuration — All Steps Together

  ! ── Hostname and domain ──────────────────────────────────────────────────
  Router(config)# hostname R1
  R1(config)# ip domain-name netstuts.com

  ! ── Local user ───────────────────────────────────────────────────────────
  R1(config)# username admin privilege 15 secret Str0ngP@ssw0rd

  ! ── RSA key pair ─────────────────────────────────────────────────────────
  R1(config)# crypto key generate rsa modulus 2048

  ! ── SSH version ──────────────────────────────────────────────────────────
  R1(config)# ip ssh version 2
  R1(config)# ip ssh time-out 60
  R1(config)# ip ssh authentication-retries 3

  ! ── VTY lines ────────────────────────────────────────────────────────────
  R1(config)# line vty 0 4
  R1(config-line)# login local
  R1(config-line)# transport input ssh
  R1(config-line)# exec-timeout 10 0
  R1(config-line)# exit

  ! ── Password encryption ──────────────────────────────────────────────────
  R1(config)# service password-encryption

6. Restricting VTY Access with an ACL

Disabling Telnet and enabling SSH is a significant improvement, but it still allows any IP address to attempt an SSH login. Adding an ACL to the VTY lines further limits which management workstations can even reach the SSH service, providing defence-in-depth.

  Goal: Allow SSH only from the management workstation at 192.168.99.10
        and the management subnet 10.99.0.0/24. Block all other sources.

  ! ── Step 1: Create the ACL (standard ACL — matches source IP) ───────────
  R1(config)# ip access-list standard MGMT_ACCESS
  R1(config-std-nacl)# remark === Permit management workstation ===
  R1(config-std-nacl)# permit host 192.168.99.10
  R1(config-std-nacl)# remark === Permit management subnet ===
  R1(config-std-nacl)# permit 10.99.0.0 0.0.255.255
  R1(config-std-nacl)# remark === Deny all other sources ===
  R1(config-std-nacl)# deny any log
  R1(config-std-nacl)# exit

  ! ── Step 2: Apply to VTY lines with access-class ─────────────────────────
  R1(config)# line vty 0 4
  R1(config-line)# access-class MGMT_ACCESS in
  R1(config-line)# exit

  ! access-class (not ip access-group) is used for VTY lines.
  ! "in" filters connection ATTEMPTS to the VTY lines (source of the SSH client).

  ! ── Result ────────────────────────────────────────────────────────────────
  ! SSH from 192.168.99.10  → permitted → reaches login prompt
  ! SSH from 10.99.1.5      → permitted → reaches login prompt
  ! SSH from 172.16.5.10    → denied by ACL → connection refused (logged)
  ! Telnet from anywhere    → rejected by "transport input ssh" (not by ACL)

access-class vs ip access-group: access-class is used under line vty to filter remote management connections. ip access-group is used under interface configurations to filter routed traffic. They use the same ACL syntax but are applied with different commands in different contexts. Using ip access-group on a VTY line will produce an error.

See: ACL Overview | Named ACLs | Applying ACLs

7. The Console Port — Securing Physical Access

While SSH secures remote (VTY) access, the console port (the direct physical management connection via a rollover cable) must also be secured. An attacker with physical access and an unsecured console port can log in without any credentials.

  Console port security best practices:

  R1(config)# line console 0
  R1(config-line)# login local                    ! require username/password
  R1(config-line)# exec-timeout 5 0               ! disconnect after 5 minutes idle
  R1(config-line)# logging synchronous            ! prevent log messages disrupting input
  R1(config-line)# exit

  ! Do NOT leave console with no authentication:
  ! (default — allows anyone with physical access to log in without credentials)
  ! line console 0
  !  login                ← requires only the line password
  !  password cisco       ← weak — same password for everyone, cleartext

  ! Best practice — use local username database:
  ! line console 0
  !  login local          ← requires username AND password from the local database
  !  exec-timeout 5 0     ← auto-logout on idle

Console vs VTY — Key Differences

Feature	Console (line con 0)	VTY (line vty 0 4)
Connection method	Physical rollover cable from PC serial/USB port	Remote network connection (SSH or Telnet)
Number of simultaneous sessions	1 (only one console port)	5 (lines 0–4) or up to 16 (lines 0–15)
Transport control	Not applicable — direct serial	`transport input ssh` restricts protocols
ACL control	Cannot use `access-class` (no network source)	`access-class <acl> in` filters by source IP
Default authentication	None (open) — must configure `login`	None (open) unless `login` or `login local` is set

8. Login Security — Brute-Force Protection

Even with SSH enforced, a determined attacker can attempt to brute-force the SSH login by trying thousands of username/password combinations. Cisco IOS provides the login block-for command to automatically block login attempts from an IP address after a configurable number of failures within a time window.

  ! Block login for 120 seconds if 5 failures occur within 60 seconds:
  R1(config)# login block-for 120 attempts 5 within 60

  ! During the block period, ALL logins are refused (except from trusted IPs).
  ! A syslog message is generated when the block is triggered.

  ! Whitelist trusted management IPs (exempt from blocking):
  R1(config)# ip access-list standard TRUSTED_MGMT
  R1(config-std-nacl)# permit host 192.168.99.10
  R1(config-std-nacl)# exit
  R1(config)# login quiet-mode access-class TRUSTED_MGMT

  ! "quiet-mode" is the state during the block period.
  ! Hosts in TRUSTED_MGMT can still log in during quiet-mode.

  ! Additional login delay (slow down brute-force even before blocking):
  R1(config)# login delay 3    ! enforce 3-second delay between login attempts

  ! Verify login security status:
  R1# show login
  Login Block-for period is 120 secs
  Login Delay is 3 sec
  Login Max-fail is 5
  Login Failure Count: 0

  R1# show login failures
  ! Shows recent failed login attempts with source IP and timestamp

login block-for requirement: The login block-for command requires that at least one VTY line has login local or AAA authentication configured. If VTY lines use only login (line password only), the block-for command may not activate.

See: Login Security & Brute-Force Protection Lab

9. Privilege Levels and Role-Based Access

Cisco IOS supports 16 privilege levels (0–15). Level 1 is the default user EXEC mode (limited read-only commands). Level 15 is full privileged EXEC (all commands). Levels 2–14 are customisable — specific commands can be assigned to specific levels, enabling role-based access control where different administrators have different capabilities.

Level	Name	Default Access
0	Minimum	Only: disable, enable, exit, help, logout
1	User EXEC	Basic show commands, ping, traceroute — no configuration
2–14	Custom	Defined by administrator — assign specific commands to levels
15	Privileged EXEC	All commands including global configuration mode

  Assigning privilege levels to users:

  ! Level 15 — full admin:
  R1(config)# username admin privilege 15 secret AdminP@ss

  ! Level 7 — network operator (show commands + interface resets, no config changes):
  R1(config)# username netops privilege 7 secret Oper@torP@ss

  ! Assign specific commands to level 7:
  R1(config)# privilege exec level 7 show running-config
  R1(config)# privilege exec level 7 debug ip packet
  R1(config)# privilege exec level 7 clear interface

  ! User at level 7 can use those commands without reaching level 15.
  ! They cannot enter global config mode (configure terminal = level 15).

  ! Verify current privilege level:
  R1# show privilege
  Current privilege level is 15

  ! Escalate privilege (if level 15 enable password is set):
  R1> enable 15
  Password: <enable secret>

See: AAA Overview | AAA Local vs RADIUS

10. Enable Password vs Enable Secret

When an SSH user connects to a device and reaches user EXEC mode, they typically need to enter enable to reach privileged EXEC mode and make configuration changes. The enable password and enable secret both protect this transition — but they are not equivalent.

Command	Storage in Config	Algorithm	Security Level
`enable password <pw>`	Plaintext (or Type 7 if service password-encryption active)	None / Vigenere (Type 7) — easily reversed	Weak — do not use
`enable secret <pw>`	Hashed — never stored as plaintext	MD5 (Type 5) by default; SHA-256 (Type 9) in modern IOS	Strong — always use this
`enable algorithm-type sha256 secret <pw>`	SHA-256 hash (Type 8)	PBKDF2 with SHA-256	Strongest — recommended for modern IOS

  ! What an enable password looks like in the config (INSECURE):
  enable password Cisco123
  ↓ After service password-encryption (still weak):
  enable password 7 0822455D0A16

  ! What an enable secret looks like in the config (SECURE):
  enable secret Cisco123
  ↓ Stored as:
  enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0

  ! Type 9 (SHA-256, recommended):
  enable algorithm-type sha256 secret Cisco123
  ↓ Stored as:
  enable secret 9 $9$H/vbHKTvdEZSSx$f8...

  Rule: If both enable password and enable secret are configured,
  enable secret ALWAYS takes precedence — enable password is ignored.
  Remove enable password if enable secret is configured:
  R1(config)# no enable password

11. Disabling Telnet — Removing the Insecure Protocol

Even if SSH is configured, Telnet remains available by default on VTY lines unless explicitly disabled. The transport input command controls which protocols are accepted on VTY lines.

  VTY transport input options:

  transport input all      ! accept Telnet AND SSH (default — insecure)
  transport input telnet   ! accept Telnet only (NEVER use in production)
  transport input ssh      ! accept SSH only (CORRECT — recommended)
  transport input none     ! accept no connections (disables VTY entirely)
  transport input telnet ssh ! accept both (not recommended)

  ! Disable Telnet and enforce SSH on all VTY lines:
  R1(config)# line vty 0 4
  R1(config-line)# transport input ssh

  ! Verify:
  R1# show line vty 0
  ...
    Allowed input transports are ssh.

  ! What happens when Telnet is attempted after "transport input ssh":
  $ telnet 192.168.1.1
  Trying 192.168.1.1...
  % Connection refused by remote host

  ! SSH connection succeeds normally:
  $ ssh -l admin 192.168.1.1
  Password: ***
  R1#

Completely Disabling Telnet on the Device

  ! Some hardening guides also recommend disabling Telnet globally,
  ! though "transport input ssh" on VTY lines is the primary control.

  ! To additionally prevent outbound Telnet FROM the router:
  R1(config)# line vty 0 4
  R1(config-line)# transport output ssh   ! restrict outbound sessions too

  ! Verify Telnet is truly blocked — from an external host:
  $ telnet 192.168.1.1 23
  telnet: connect to address 192.168.1.1: Connection refused

12. Verification and Troubleshooting Commands

  ! Show SSH status, version, timeout, and retries:
  R1# show ip ssh
  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):
  ssh-rsa AAAAB3NzaC1...

  ! Show all active VTY sessions (SSH and Telnet):
  R1# show users
      Line       User       Host(s)              Idle       Location
  *  0 con 0    admin      idle                 00:00:00
     2 vty 0    netops     192.168.99.10        00:02:14   SSH

  ! Show detailed information about active SSH sessions:
  R1# show ssh
  Connection Version Mode  Encryption  Hmac         State    Username
  0          2.0     IN    aes256-ctr  hmac-sha2-256 Session started  admin
  0          2.0     OUT   aes256-ctr  hmac-sha2-256 Session started  admin

  ! Show VTY line configuration including transport settings:
  R1# show line vty 0 4
  R1# show running-config | section line vty

  ! Show the RSA key pair:
  R1# show crypto key mypubkey rsa

  ! Show login security status and recent failures:
  R1# show login
  R1# show login failures

  ! Terminate a specific active session (disconnect an admin):
  R1# clear line vty 2    ! disconnects session on VTY line 2

Common SSH Troubleshooting Issues

Symptom	Likely Cause	Fix
SSH disabled — cannot connect	RSA key not generated, or missing domain name	Verify with `show ip ssh`; generate key with `crypto key generate rsa modulus 2048`
Connection refused on port 22	VTY lines not configured for SSH transport, or ACL blocking the source IP	Check `transport input ssh` on VTY lines; check `access-class` ACL
Authentication failure	Username not in local database, wrong password, or `login local` not set on VTY	Verify with `show running-config \| section line vty`; confirm username exists with `show running-config \| section username`
SSH v1 only available	`ip ssh version 2` not configured, or RSA key too small (<768 bits)	Configure `ip ssh version 2`; regenerate RSA key with `crypto key generate rsa modulus 2048`
Session times out immediately	`exec-timeout` set too low on VTY lines	Adjust with `exec-timeout <min> <sec>` — use `exec-timeout 0 0` for no timeout (lab only)
All logins blocked during quiet-mode	`login block-for` triggered by failed attempts	Wait for block period to expire, or use console port to enter `clear login quiet-mode`

13. SSH and Telnet Summary — Key Facts

Topic	Key Fact
Telnet port	TCP 23 — cleartext; never use in production
SSH port	TCP 22 — encrypted session; industry standard
SSH version	Always use SSHv2 (`ip ssh version 2`); SSHv1 has known weaknesses
Prerequisites for SSH	Hostname, IP domain name, RSA key pair, local username
RSA key size	Minimum 768 bits for SSHv2; 2048 bits recommended for production
VTY transport command	`transport input ssh` — blocks Telnet; allows SSH only
VTY authentication	`login local` — uses local username database; required for SSH
VTY ACL command	`access-class <acl> in` — filters by source IP; not `ip access-group`
Enable secret vs password	Always use `enable secret` (hashed); never `enable password` (reversible)
Brute-force protection	`login block-for <sec> attempts <n> within <sec>`
Idle session timeout	`exec-timeout <min> <sec>` on VTY lines
Privilege levels	0–15; privilege 15 = full access; use `username ... privilege` to control access per user

14. SSH vs Telnet Security Quiz

1. Why is Telnet considered insecure for managing network devices, and what specific risk does this create?

A. Telnet does not support username authentication — only a line password can be used B. Telnet transmits all data — including usernames, passwords, and every command typed — in cleartext. Any attacker who can capture packets on the network path (MITM, packet sniffer, rogue device) can read the entire session, obtaining full administrative credentials. C. Telnet uses UDP, making it unreliable for remote management D. Telnet is insecure because it uses a well-known port number (23) that firewalls always block

Correct answer is B. Telnet's fundamental flaw is that it provides no encryption whatsoever. Every character sent during a Telnet session — including the username, password, enable password, and all configuration commands — is transmitted as raw ASCII text. A Wireshark capture on any network segment in the path reveals the complete session. Telnet uses TCP (not UDP), so option C is also factually wrong. The port number (23) being well-known is a minor issue compared to the cleartext transmission problem.

2. What are the four prerequisites that must be configured before SSH can be enabled on a Cisco IOS device?

A. IP address, default gateway, enable password, and NTP server B. OSPF routing, VLANs, ACLs, and AAA server C. IP address, SSH version, VTY password, and service password-encryption D. A unique hostname (not default), an IP domain name (ip domain-name), an RSA key pair (crypto key generate rsa), and a local username (username ... secret)

Correct answer is D. These four prerequisites are required in order: (1) Hostname — must be set to something other than the default "Router" or "Switch" because it forms part of the RSA key label. (2) IP domain name — required to form the fully qualified key label (hostname.domain). Without it, crypto key generate rsa is rejected. (3) RSA key pair — the cryptographic foundation of SSH; without it, SSH is disabled. (4) Local username — SSH requires username-based authentication (login local); a VTY line password alone is not sufficient for SSH.

3. What RSA key modulus size is recommended for production SSH deployments on Cisco IOS, and what is the minimum required for SSHv2?

A. Recommended: 2048 bits; Minimum for SSHv2: 768 bits. Use crypto key generate rsa modulus 2048 in production. Keys smaller than 768 bits cannot enable SSHv2. B. Recommended: 512 bits; Minimum: 256 bits C. Recommended: 1024 bits; Minimum: 512 bits D. There is no minimum — any key size enables SSHv2

Correct answer is A. The minimum RSA key modulus to enable SSHv2 on Cisco IOS is 768 bits. However, 768 and 1024-bit keys are considered weak by modern cryptographic standards. The recommended minimum for production environments is 2048 bits. High-security environments may use 4096 bits. If you attempt ip ssh version 2 without generating a key of at least 768 bits, the router outputs: "%Please create RSA keys (of at least 768 bits size) to enable SSH v2."

4. What is the correct command to restrict VTY lines to accept only SSH connections and reject all Telnet attempts?

A. transport output ssh B. ip access-group ssh-only in C. transport input ssh — configured under line vty 0 4. This replaces the default transport input all and causes the router to reject any Telnet connection attempt with "connection refused." D. no transport input telnet

Correct answer is C. The transport input command under line vty controls which protocols are accepted for inbound connections. The default is transport input all (allows both Telnet and SSH). Changing it to transport input ssh means only SSH connections are accepted — Telnet attempts receive "connection refused." transport output controls outbound sessions FROM the router, not inbound. no transport input telnet is not valid Cisco IOS syntax for this purpose.

5. What is the difference between `enable password` and `enable secret`, and which should always be used?

A. They are identical — both store the password using strong SHA-256 hashing B. enable password stores the password in plaintext (or weak reversible Type 7 encryption). enable secret stores a one-way MD5 or SHA-256 hash that cannot be reversed. Always use enable secret. If both are configured, enable secret takes precedence. C. enable password is for SSH access; enable secret is for console access D. enable secret only works on modern IOS — use enable password for compatibility

Correct answer is B. This is a frequently tested CCNA security topic. enable password <pw> stores the password in plaintext in the running-config, or in reversible Type 7 (Vigenere) encoding if service password-encryption is active — both can be decoded trivially. enable secret <pw> uses a one-way hash (MD5 Type 5, or SHA-256 Type 8/9 in modern IOS) that cannot be reversed. An attacker who obtains the running-config cannot recover the original password from the hash. If both commands exist in the config, enable secret always wins and enable password is completely ignored.

6. An administrator applies a standard ACL to the VTY lines to restrict management access. Which command correctly applies the ACL, and what is the common mistake?

A. ip access-group MGMT_ACL in under line vty 0 4 B. ip access-group MGMT_ACL in under the management interface C. access-class MGMT_ACL out under line vty 0 4 D. access-class MGMT_ACL in under line vty 0 4. The common mistake is using ip access-group (which is for physical interfaces, not VTY lines) instead of access-class.

Correct answer is D. VTY lines use access-class, not ip access-group. ip access-group is the command for applying an ACL to a physical or logical network interface (Gi0/0, Vlan10, etc.) for filtering routed traffic. access-class is specifically for VTY and console lines and filters remote management connection attempts by source IP. The direction in filters inbound connections (who can connect to this router). The direction out filters outbound connections (which hosts this router can Telnet/SSH to).

7. After configuring SSH on a router, a network engineer runs `show ip ssh` and sees "SSH Disabled - version 2.0 %Please create RSA keys of at least 768 bits." What must be done?

A. Generate an RSA key pair with at least 768 bits using crypto key generate rsa modulus 2048. SSH cannot function without an RSA key pair — this is one of the four SSH prerequisites. B. Configure ip ssh version 2 again to activate SSH C. Reload the router to generate automatic keys D. Configure a line vty password to enable SSH

Correct answer is A. The error message explicitly states the problem — no RSA key pair exists (or the existing key is smaller than 768 bits). The RSA key pair is the cryptographic foundation of SSH on Cisco IOS. Without it, SSH is disabled regardless of other configuration. The fix is crypto key generate rsa modulus 2048 (enter this in global config mode after confirming the hostname and domain name are set). The router will generate the key and SSH will become active immediately — no reload required.

8. What does the command `login block-for 120 attempts 5 within 60` do, and what is the purpose of `login quiet-mode access-class TRUSTED`?

A. It blocks specific usernames for 120 seconds after 5 failed logins; quiet-mode allows any user to bypass the block B. It sets the session timeout to 120 seconds and limits sessions to 5 total; quiet-mode controls idle behaviour C. If 5 failed login attempts occur within 60 seconds, ALL login attempts are blocked for 120 seconds (quiet-mode). The login quiet-mode access-class TRUSTED command specifies an ACL of trusted IP addresses that are exempt from the block and can still log in during the quiet-mode period. D. It limits SSH sessions to 5 simultaneous connections and disconnects them after 120 seconds

Correct answer is C. login block-for is Cisco's built-in brute-force protection. It monitors failed login attempts: if the threshold is exceeded (5 failures within 60 seconds in this example), the router enters "quiet mode" and refuses ALL login attempts for the block period (120 seconds). This prevents automated password-guessing attacks. The risk is that a legitimate administrator might also be locked out during quiet mode. The login quiet-mode access-class command mitigates this by designating trusted source IPs (e.g., the management workstation) that can still authenticate even during quiet mode.

9. A router has both `enable password Cisco123` and `enable secret SecurePass` configured. When an administrator types `enable`, which password is required?

A. Either password is accepted — the router tries both B. SecurePass — when both are configured, enable secret always takes precedence and enable password is completely ignored C. Cisco123 — enable password is checked first as the primary credential D. The router uses whichever was configured most recently

Correct answer is B. When both enable password and enable secret exist in the configuration, Cisco IOS always uses enable secret. The enable password is completely bypassed and ignored. This means typing Cisco123 will fail — only SecurePass is accepted. Best practice is to remove enable password entirely when enable secret is configured: no enable password. Having both in the config is misleading and provides no additional security.

10. An administrator has fully configured SSHv2 with a 2048-bit RSA key, restricted VTY lines to SSH only, and applied an ACL. A security audit still flags one remaining risk. The VTY lines have `exec-timeout 0 0`. What is the risk and what is the fix?

A. exec-timeout 0 0 disables SSH — set it to exec-timeout 22 22 to re-enable B. exec-timeout 0 0 enables Telnet — remove it to disable Telnet access C. There is no risk — exec-timeout 0 0 is the recommended production setting D. exec-timeout 0 0 means idle sessions NEVER disconnect automatically. If an administrator's SSH session is left unattended, it remains active indefinitely — an attacker with access to the workstation can take over the live authenticated session. Fix: set a reasonable timeout such as exec-timeout 10 0 (10 minutes) to auto-disconnect idle sessions.

Correct answer is D. exec-timeout controls how long an idle VTY session remains open before the router automatically disconnects it. The syntax is exec-timeout <minutes> <seconds>. exec-timeout 0 0 sets both to zero, meaning the session never times out regardless of inactivity. While convenient in a lab environment (avoiding repeated logins), this is a significant security risk in production: an authenticated but idle session on an unattended workstation is an open door to the device. Best practice is exec-timeout 10 0 (10 minutes) for production networks. Some high-security environments use 5 minutes or less.

← Back to Home

SSH vs Telnet – Securing Remote Access

1. Remote Access to Network Devices — Why It Matters

2. Why Telnet Is Insecure — The Cleartext Problem

Telnet Packet Capture — What an Attacker Sees

Attack Vectors for Telnet

3. How SSH Secures the Session

SSH Session Establishment — Step by Step

SSH v1 vs SSH v2

4. SSH Configuration Prerequisites on Cisco IOS

5. Full SSH v2 Configuration — Step by Step

Step 1 — Set Hostname and Domain Name

Step 2 — Create Local User Account

Step 3 — Generate RSA Key Pair

Step 4 — Specify SSH Version 2

Step 5 — Configure VTY Lines for SSH Only

Step 6 — Enable Password Encryption (Global)

Step 7 — Set SSH Timeout and Retry Parameters

Complete Configuration — All Steps Together

6. Restricting VTY Access with an ACL

7. The Console Port — Securing Physical Access

Console vs VTY — Key Differences

8. Login Security — Brute-Force Protection

9. Privilege Levels and Role-Based Access

10. Enable Password vs Enable Secret

11. Disabling Telnet — Removing the Insecure Protocol

Completely Disabling Telnet on the Device

12. Verification and Troubleshooting Commands

Common SSH Troubleshooting Issues

13. SSH and Telnet Summary — Key Facts

14. SSH vs Telnet Security Quiz

1. Why is Telnet considered insecure for managing network devices, and what specific risk does this create?

2. What are the four prerequisites that must be configured before SSH can be enabled on a Cisco IOS device?

3. What RSA key modulus size is recommended for production SSH deployments on Cisco IOS, and what is the minimum required for SSHv2?

4. What is the correct command to restrict VTY lines to accept only SSH connections and reject all Telnet attempts?

5. What is the difference between enable password and enable secret, and which should always be used?

6. An administrator applies a standard ACL to the VTY lines to restrict management access. Which command correctly applies the ACL, and what is the common mistake?

7. After configuring SSH on a router, a network engineer runs show ip ssh and sees "SSH Disabled - version 2.0 %Please create RSA keys of at least 768 bits." What must be done?

8. What does the command login block-for 120 attempts 5 within 60 do, and what is the purpose of login quiet-mode access-class TRUSTED?

9. A router has both enable password Cisco123 and enable secret SecurePass configured. When an administrator types enable, which password is required?

10. An administrator has fully configured SSHv2 with a 2048-bit RSA key, restricted VTY lines to SSH only, and applied an ACL. A security audit still flags one remaining risk. The VTY lines have exec-timeout 0 0. What is the risk and what is the fix?

5. What is the difference between `enable password` and `enable secret`, and which should always be used?

7. After configuring SSH on a router, a network engineer runs `show ip ssh` and sees "SSH Disabled - version 2.0 %Please create RSA keys of at least 768 bits." What must be done?

8. What does the command `login block-for 120 attempts 5 within 60` do, and what is the purpose of `login quiet-mode access-class TRUSTED`?

9. A router has both `enable password Cisco123` and `enable secret SecurePass` configured. When an administrator types `enable`, which password is required?

10. An administrator has fully configured SSHv2 with a 2048-bit RSA key, restricted VTY lines to SSH only, and applied an ACL. A security audit still flags one remaining risk. The VTY lines have `exec-timeout 0 0`. What is the risk and what is the fix?