A cooperative's security policy requires that administrators never log in directly as root over the network, so every action can be tied to a named account. Which Junos configuration approach enforces this?
Select an answer to reveal the explanation.
Short Explanation
You can't have accountability if everyone's logging in as the same generic superuser. Junos lets you tell SSH specifically not to allow root straight through the front door, so every technician has to sign in under their own name first.
Full Explanation
Junos allows the SSH service, configured under the system services hierarchy, to control whether the root account can authenticate directly over SSH, independent of whether root-authentication is otherwise configured. Restricting or denying root-login there is precisely the mechanism for enforcing a policy that every administrative session be tied to a named individual account rather than the shared root identity, supporting accountability and audit trails. Removing the root-authentication password entirely is not a valid substitute — root still needs a password set for local console access and, as covered elsewhere, Junos won't even allow a commit without one, so eliminating it breaks basic device administration rather than improving security. The root account's login class is fixed as super-user by the nature of the account itself; login classes aren't reassigned to root to limit its scope, and doing so isn't how Junos manages root access restriction. The host-name statement is purely a cosmetic identification label and plays no role whatsoever in access control or authentication policy. In practice, a cooperative enforcing this policy should verify it by attempting an SSH login as root from a workstation and confirming Junos rejects it, then confirming each technician's named account and login class combination works as expected.