Secure Shell (SSH) is the industry standard for secure remote Linux administration, operating by default on TCP port 22. In the context of CompTIA Linux+, securing the SSH daemon (`sshd`) is a primary system hardening task, primarily managed via the `/etc/ssh/sshd_config` file.
The most critical c…Secure Shell (SSH) is the industry standard for secure remote Linux administration, operating by default on TCP port 22. In the context of CompTIA Linux+, securing the SSH daemon (`sshd`) is a primary system hardening task, primarily managed via the `/etc/ssh/sshd_config` file.
The most critical configuration step is disabling direct root login by setting `PermitRootLogin no`. This forces attackers to guess a valid username rather than targeting 'root' and ensures that legitimate administrators log in as unprivileged users before elevating rights via `sudo`, creating a better audit trail. Furthermore, password-based authentication should be disabled (`PasswordAuthentication no`) in favor of SSH Key-based authentication (Public Key Infrastructure). This method, which uses a private key on the client and a public key within the server's `~/.ssh/authorized_keys` file, renders traditional dictionary and brute-force password attacks useless.
Access control should be strictly defined using the `AllowUsers` or `AllowGroups` directives to whitelist specific entities. Administrators often change the default listening port to a non-standard number to bypass automated scanning scripts, although this is considered security by obscurity. Additionally, ensuring the use of SSH Protocol 2 is mandatory to avoid vulnerabilities found in Protocol 1. It is also best practice to disable X11 forwarding (`X11Forwarding no`) if GUI tunneling is unnecessary to reduce the attack surface.
On the file system level, strict permissions are required: the `.ssh` directory must be set to `700`, and private keys to `600`. Finally, SSH security should be reinforced by external tools like Fail2Ban, which monitors `/var/log/auth.log` to dynamically ban IPs exhibiting brute-force behavior, and host-based firewalls (such as `ufw` or `iptables`) that restrict SSH traffic to trusted management subnets.
Master Guide: SSH Configuration and Security for CompTIA Linux+
What is SSH and Why is it Important?
SSH (Secure Shell) is a cryptographic network protocol used to operate network services securely over an unsecured network. Typically running on TCP Port 22, it provides a secure channel over an unsecured network in a client-server architecture.
Its primary importance lies in replacing insecure legacy protocols like Telnet and rlogin, which transmitted data (including passwords) in plain text. SSH provides confidentiality (encryption), integrity (hashing), and authentication (proving identity), making it the de facto standard for remote Linux server administration.
How SSH Works
SSH utilizes a client-server model. A daemon called sshd runs on the server, listening for connections, while a client (like the ssh command) initiates the connection.
The security relies on public-key cryptography. When a connection is established, a handshake occurs to negotiate encryption methods. The server sends its public host key to the client to verify the server's identity (preventing Man-in-the-Middle attacks). Authentication then follows, utilizing either a username/password or, more securely, SSH key pairs.
Key Configuration Files
For the CompTIA Linux+ exam, you must master the configuration files located in /etc/ssh/:
1. /etc/ssh/sshd_config: The configuration file for the SSH server (daemon). This is where you harden the system. 2. /etc/ssh/ssh_config: The global configuration file for the SSH client. 3. ~/.ssh/authorized_keys: Located in a user's home directory on the server. Contains the public keys of clients allowed to log in as that user. 4. ~/.ssh/known_hosts: Operations on the client side; stores the fingerprints of servers the client has connected to previously.
SSH Security Hardening
Pass the Linux+ exam requires knowing how to secure a server by editing /etc/ssh/sshd_config. Common hardening measures include:
1. Disabling Root Login Prevent direct root access to unauthorized users. Directive:PermitRootLogin no
2. Disabling Password Authentication Force the use of SSH Keys, which are immune to brute-force password guessing. Directive:PasswordAuthentication no
3. Changing the Default Port Security by obscurity to reduce log noise from automated bots scanning port 22. Directive:Port 2022 (or any unused non-privileged port)
4. Limiting Users Specifically allow only certain users or groups. Directive:AllowUsers jerry tom or AllowGroups sysadmins
5. SSH Protocol Version Ensure only Protocol 2 is used (Protocol 1 is insecure). Directive:Protocol 2
Managing SSH Keys
You must know the CLI tools associated with key management: ssh-keygen: Generates a public/private key pair (usually id_rsa and id_rsa.pub). ssh-copy-id user@host: Copies the client's public key to the server's authorized_keys file automatically. ssh-agent: Holds private keys used for public key authentication so you don't have to type the passphrase every time.
Exam Tips: Answering Questions on SSH Configuration and Security
1. Differentiate Server vs. Client Config Exam questions often try to trick you by mixing up config files. Remember: if you are configuring the server behaviors (like who can log in), you are editing sshd_config (note the 'd' for daemon). If you are configuring how you connect to others, it is ssh_config.
2. Syntax Precision Pay attention to the directives. For example, PermitRootLogin takes arguments like yes, no, or without-password. If a question asks how to allow root login only via keys, the answer is without-password or prohibit-password (depending on version), not simply "yes".
3. Permissions Matter SSH is sensitive to file permissions. If ~/.ssh is writable by others, or private keys (id_rsa) are readable by others (anything other than 600), SSH will often refuse to run or accept the key. Look for permission issues in troubleshooting questions.
4. Restarting Services Config changes do not take effect until the service is restarted. If a scenario describes a user changing the config but the behavior remaining the same, the missing step is usually systemctl restart sshd.
5. Identifying Public vs. Private Never share the private key. If an exam scenario involves moving keys, ensure the .pub file goes to the remote server, and the private key stays on the local client.