A library consortium will retire clear-text remote CLI on all municipal routers. Which management access method should replace Telnet?
Select an answer to reveal the explanation.
Short Explanation
Telnet is a postcard — anyone on the path can read the CLI. SSH is a sealed envelope for the same remote shell work. Libraries swapping Telnet for SSH are just refusing to mail passwords in the clear.
Full Explanation
Municipal routers that still expose clear-text Telnet put credentials and configuration commands on the wire for anyone who can capture traffic. SSH replaces Telnet for remote CLI by encrypting the session in transit, which is the standard secure management method the library consortium should adopt when retiring clear-text remote access. Operators keep remote administration capability without sending passwords and keystrokes in plaintext.
Continuing Telnet and hoping long usernames provide confidentiality does not encrypt the channel; usernames are not a substitute for transport security. HTTP without TLS for CLI-through-browser merely moves clear-text management to another protocol. Disabling every remote protocol and forcing FTP for configuration changes removes manageable remote CLI and introduces another clear-text file-transfer risk rather than solving confidentiality.
Exam caveat: SSH should be paired with strong authentication (local privilege discipline or AAA), updated crypto settings, and VTY ACLs. Encrypting the session does not by itself authorize who may log in. Also retain console access for out-of-band recovery when the in-band path fails.
Operational check: disable Telnet on VTY lines, enable SSHv2, verify a management station can open an SSH session to a library router, and confirm a packet capture on the path no longer shows plaintext credentials.