A cooperative's network team is deciding how field techs should remotely access routers at unmanned rural POPs for day-to-day monitoring. Why should SSH be chosen over Telnet for this access?
Select an answer to reveal the explanation.
Short Explanation
Telnet is like discussing a login password over an open two-way radio anyone nearby could tune into. SSH puts that same conversation in a locked, encrypted channel, which matters a lot when the traffic between a tech's laptop and an unmanned rural POP could cross links you don't fully control.
Full Explanation
The real distinction between the two protocols is confidentiality: SSH establishes an encrypted session using key exchange and symmetric encryption, while Telnet transmits everything — including the login username and password — as cleartext that anyone with visibility into the path can read with a packet capture. For an unmanned rural POP, where the management path may traverse shared transit or third-party infrastructure, that exposure is a meaningful risk, since a captured credential grants full administrative access to the device. Both protocols are fully capable of carrying any operational-mode or configuration-mode command once a session is established, so the claim that Telnet is limited to configuration commands is simply incorrect — the limitation is security, not command scope. Telnet is, in fact, supported on Junos devices (it can be enabled under system services), so ruling it out as unsupported misstates the actual concern, which is that it should be disabled in favor of SSH rather than that it's unavailable. Session-count limits are a configurable login-class and system-services setting on both protocols, not an inherent advantage of one over the other. A concrete operational check: confirm telnet is not present under show configuration system services and that SSH is the only remote-access protocol enabled for management.