mediumMultiple Select

SSH Hardening: Key-Based Auth and Root Login Restrictions

A Linux administrator is hardening a server. Which TWO actions are effective in preventing unauthorized access via SSH? (Select TWO.)

Quick Answer

The answer is to set PasswordAuthentication no and use SSH keys, as disabling password authentication forces the use of key-based authentication, which is far more resistant to brute-force attacks than passwords. This works because SSH keys use asymmetric cryptography, where a private key remains on the client and a public key is stored on the server, making it computationally infeasible for an attacker to authenticate without possession of the private key. On the CompTIA Linux+ XK0-005 exam, this concept tests your understanding of the sshd_config directives, and a common trap is confusing PermitRootLogin no with PasswordAuthentication no—remember that disabling root login is a separate, complementary control that prevents direct root access, not password-based logins. A useful memory tip is “keys over passwords, root over sudo,” reinforcing that both settings together create layered defense.

⚠ Common exam trap

A common mix-up: candidates think disabling the SSH service (Option C) is a valid hardening step, but the question asks for actions that prevent unauthorized access *via SSH* while still allowing legitimate remote administration.

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

✓

Set PermitRootLogin no in /etc/ssh/sshd_config

Option D is correct because setting PermitRootLogin no in /etc/ssh/sshd_config prevents direct root logins over SSH, forcing attackers to compromise a normal user account first and eliminating the most privileged and commonly brute-forced target. Option E is correct because setting PasswordAuthentication no disables password-based authentication entirely, so only SSH key pairs are accepted, which defeats brute-force and credential-guessing attacks since keys cannot be feasibly guessed. The unmarked options do not belong: PermitRootLogin yes (A) explicitly allows direct root SSH access, the opposite of hardening; PasswordAuthentication yes (B) keeps password logins enabled and thus brute-forceable; and disabling the SSH service (C) would block legitimate remote administration rather than secure it, which is not a practical hardening action for a server that must be administered remotely.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Set PermitRootLogin yes
Why it's wrong here
Setting PermitRootLogin yes directly permits direct root logins over SSH, defeating the hardening goal by removing the accountability and privilege-escalation barrier that a non-root account provides. It is tempting because root access is sometimes needed for administrative tasks, but PermitRootLogin no with sudo or su is the correct hardening configuration.
✗
Set PasswordAuthentication yes
Why it's wrong here
Setting PasswordAuthentication yes permits password-based logins, which are vulnerable to brute-force and credential-stuffing attacks — the opposite of hardening. It is tempting because passwords are the default authentication method and remain valid for interactive logins; however, key-based authentication with PasswordAuthentication no is the correct hardening choice for restricting unauthorised SSH access.
✗
Disable the SSH service
Why it's wrong here
Disabling the SSH service removes remote administration entirely, so it cannot prevent unauthorised access while preserving legitimate SSH connectivity the scenario requires. It is tempting because decommissioning SSH is valid for hosts that must never accept remote shell sessions, such as isolated appliances or bastion-free hardened kiosks.
✓
Set PermitRootLogin no in /etc/ssh/sshd_config
Why this is correct
PermitRootLogin no blocks direct root logins over SSH, forcing administrators to authenticate as an unprivileged user before escalating. This removes the highest-value target an attacker could reach through the SSH daemon, satisfying the hardening requirement.
✓
Set PasswordAuthentication no and use SSH keys
Why this is correct
Disabling password authentication removes the credential-guessing attack surface entirely, since SSH accepts only cryptographic key proofs. This satisfies the hardening requirement because stolen or brute-forced passwords become useless, though keys must be protected and passphrase-secured.

Go deeper

1 more way this is tested on XK0-006

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. An administrator needs to ensure that the SSH service only allows key-based authentication and disables password authentication. Which configuration file and directive should be modified?

medium

A./etc/ssh/sshd_config; PasswordAuthentication yes
B./etc/ssh/sshd_config; PubkeyAuthentication no
C./etc/ssh/ssh_config; PasswordAuthentication no
✓ D./etc/ssh/sshd_config; PasswordAuthentication no

Why D: The SSH server configuration file is /etc/ssh/sshd_config, and setting 'PasswordAuthentication no' disables password-based logins, forcing key-based authentication. This directive must be set on the server side (sshd_config), not the client side (ssh_config), to enforce the policy for all incoming SSH connections.

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.

SSH Hardening: Key-Based Auth and Root Login Restrictions

Why each option matters

Option-by-option breakdown

Related to this question

1 more way this is tested on XK0-006