Pearson XK0-005 New Attempt

Some good security practices when hardening a Linux server are:

• Removing unnecessary packages (B) to reduce the attack surface and eliminate potential vulnerabilities
• Disabling the SSH root login possibility (E) to prevent unauthorized access and brute-force attacks on the root account References:
• [CompTIA Linux+ Study Guide], Chapter 9: Securing Linux, Section: Hardening Linux
• [How to Harden Your Linux Server]

These commands can display all the firewall rules applied to the Linux servers, depending on which firewall service is being used.

• The firewall-cmd command is a utility for managing firewalld, which is a dynamic firewall service that supports zones and services. The --list-all option will show all the settings and rules for the default zone, or for a specific zone if specified. For example, firewall-cmd --list-all --zone=public will show the rules for the public zone1.
• The ufw command is a frontend for iptables, which is a low-level tool for manipulating netfilter, the Linux kernel’s packet filtering framework. The status option will show the status of ufw and the active rules, or the numbered rules if verbose is specified. For example, ufw status verbose will show the numbered rules and other information2.

The other options are incorrect because:

A. ufw limit

This command will limit the connection attempts to a service or port using iptables’ recent module. It does not display any firewall rules2.

B. iptables -F

This command will flush (delete) all the rules in the selected chain, or all chains if none is given. It does not display any firewall rules3.

C. systemctl status firewalld

This command will show the status of the firewalld service, including whether it is active or not, but it does not show the firewall rules4.

F. iptables -A

This command will append one or more rules to the end of the selected chain. It does not display any firewall rules3.

The command that would resolve the issue is chmod 600 .ssh/authorized_keys. This command will change the permissions of the .ssh/authorized_keys file to 600, which means that only the owner of the file can read and write it. This is necessary for SSH key authentication to work properly, as SSH will refuse to use a key file that is accessible by other users or groups for security reasons. The output of ls -l shows that currently the .ssh/authorized_keys file has permissions of 664, which means that both the owner and group can read and write it, and others can read it.

The other options are not correct commands for resolving the issue. The restorecon .ssh/authorized_keys command will restore the default SELinux security context for the .ssh/authorized_keys file, but this will not change its permissions or ownership. The ssh_keygen -t rsa -o .ssh/authorized_keys command is invalid because ssh_keygen is not a valid command (the correct command is ssh-keygen), and the -o option is used to specify a new output format for the key file, not the output file name. The chown root:root .ssh/authorized_keys command will change the owner and group of the .ssh/authorized_keys file to root, but this will not change its permissions or make it accessible by the user who wants to log in with SSH key authentication. References: How to Use Public Key Authentication with SSH; chmod(1) - Linux manual page