XK0-006 Security Practice Question
An administrator is hardening SSH and wants to disable root login and only allow users in the 'sshusers' group. Which two directives should be set in /etc/ssh/sshd_config?
⚠ Common exam trap
Many exam-takers confuse `AllowGroups` with `AllowUsers` — candidates often pick `AllowUsers sshusers` thinking it restricts to the group, but it actually restricts to a user named 'sshusers', not group membership.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
PermitRootLogin no and AllowGroups sshusers
The directive `PermitRootLogin no` explicitly disallows root login via SSH, and `AllowGroups sshusers` restricts SSH access to only members of the 'sshusers' group. This combination meets both requirements: disabling root login and limiting access to a specific group. The `AllowGroups` directive is group-based, unlike `AllowUsers`, which is user-based.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
DenyRootLogin yes and AllowGroups sshusers
Why it's wrong here
DenyRootLogin is not a valid sshd_config directive, so root login remains permitted; the correct keyword is PermitRootLogin. AllowGroups sshusers is right, but pairing it with a non-existent directive leaves the hardening incomplete. DenyUsers and DenyGroups exist for blocklists, which is where administrators sometimes expect a 'Deny' prefix to apply.
- ✗
PermitRootLogin prohibit-password and AllowGroups sshusers
Why it's wrong here
PermitRootLogin prohibit-password still allows root to log in using an SSH key, so root login is not fully disabled as required. It is tempting because it blocks password-based root access, and would be correct where key-based root login must remain available for administrative tasks.
- ✓
PermitRootLogin no and AllowGroups sshusers
Why this is correct
PermitRootLogin no blocks direct superuser SSH access, forcing administrators to log in as themselves before elevating. AllowGroups sshusers restricts authentication to members of that group via the AllowGroups directive, satisfying both hardening constraints. DenyUsers or AllowUsers would not reference group membership.
- ✗
PermitRootLogin no and AllowUsers sshusers
Why it's wrong here
AllowUsers matches individual account names, not group names, so listing 'sshusers' grants access only to a literal user called sshusers and locks out every group member. PermitRootLogin no is correct. AllowGroups is the directive that filters by group membership, which is what the scenario requires.
Go deeper
Related to this question
Learn chapter
User and Group Administration
Key term
User
A user is any person, system, or device that interacts with an IT service, resource, or identity system, typically authenticated through credentials and authorized to perform specific actions.
Key term
SSH
SSH (Secure Shell) is a cryptographic network protocol that provides secure, encrypted communication and remote administration between two devices over an unsecured network.
About these practice questions
Courseiva writes every XK0-006 question from scratch — 781 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This XK0-006 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the XK0-006 exam.