/etc/ssh/sshd_config and then restart or reload the sshd service. This ensures that security hardening measures, such as disabling root login or changing the default port, survive system reboots and do not revert to defaults. Always back up the original configuration before making changes to prevent lockout scenarios.
Locating and Backing Up the Configuration File
The primary configuration file for the OpenSSH server is located in the/etc/ssh/ directory. The specific file you need to modify is named sshd_config. Before making any edits, it is critical to create a backup copy. This safety net allows you to restore the previous state if a syntax error prevents the SSH service from starting.
Run the following command to create a timestamped backup:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
This command copies the current active configuration to a new file with the .bak extension. If you encounter issues after editing, you can simply copy this backup back over the active file. Using a text editor like nano or vim with sudo privileges is the standard approach for editing this file. For example:
sudo nano /etc/ssh/sshd_config
Essential Security Hardening Steps
Hardening your SSH daemon is the most common reason for persistent configuration. Several directives insshd_config significantly reduce the attack surface of your server. You should review and adjust the following key settings.
First, disable root login via SSH. Allowing direct root access is a major security risk because it exposes the highest privilege account to brute-force attacks. Find the line starting with PermitRootLogin and change it to:
PermitRootLogin no
Next, consider disabling password authentication entirely in favor of key-based authentication. Passwords are susceptible to guessing and phishing. To enforce key-only access, set:
PasswordAuthentication no
If you still require password authentication for specific legacy systems, ensure that empty passwords are rejected by setting:
PermitEmptyPasswords no
Another important setting is X11Forwarding. Unless you specifically need to run graphical applications remotely, this feature should be disabled to prevent potential X11 security vulnerabilities. Set it to:
X11Forwarding no
For more advanced security, you can restrict which users or groups are allowed to log in using the AllowUsers or AllowGroups directives. This creates an explicit whitelist, ensuring that only designated accounts can establish SSH connections.
Changing the Default Port
While not a strict security measure (since attackers scan all ports), changing the default SSH port from 22 to a non-standard port reduces noise from automated bots scanning the internet. Look for thePort directive near the top of the file and uncomment it if necessary. Change the value to your desired port, for example:
Port 2222
Remember that if you change the port, you must also update your firewall rules to allow traffic on the new port. Failure to do so will result in immediate loss of connectivity.
Validating Configuration Syntax
Before restarting the service, you must verify that your configuration file contains no syntax errors. The OpenSSH daemon provides a built-in test mode for this purpose. Run the following command:sudo sshd -t
If the command returns no output, the configuration is valid. If there are errors, the command will print the specific line number and description of the problem. Fix these errors in sshd_config and run the test again until it passes silently. This step is crucial because a syntax error can prevent the SSH service from starting, potentially locking you out of your server if you are connected remotely.
Applying Changes Persistently
Once the configuration is validated, you need to apply the changes. You have two options: reloading the service or restarting it. Reloading is generally preferred because it maintains existing connections while applying new configurations to new sessions. However, certain changes, like altering the port or protocol version, may require a full restart. To reload the service:sudo systemctl reload sshd
To restart the service completely:
sudo systemctl restart sshd
After applying changes, test the connection from another machine or a different terminal session to ensure that the new settings are active. Do not close your current session until you have verified that the new configuration works correctly.
Handling Related Issues
Sometimes, configuration changes lead to unexpected behaviors, such as permission denied errors when using keys. If you find that your key-based authentication fails after configuring the daemon, check the permissions on theauthorized_keys file. You may need to manually add keys or fix ownership issues. For detailed guidance on resolving permission issues related to SSH keys, refer to our guide on Fixing "Permission denied» with OpenSSH: Manually adding authorized_keys.
Additionally, if you notice high CPU usage after making configuration changes, it might indicate a misconfiguration causing excessive logging or processing loops. In such cases, monitoring the daemon's resource consumption is essential. See our analysis on Resolving High CPU Usage by a Daemon Process in Plesk Linux VPS for troubleshooting steps that apply to daemon-related performance issues.
Frequently Asked Questions
How do I revert to the default SSH configuration?
You can restore the default configuration by replacing your modified file with the backup you created earlier. Simply use the command sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config and then restart the SSH service. This returns all settings to their distribution defaults.
Why does my SSH connection fail after changing the port?
If you change the port in sshd_config but do not update your firewall rules, incoming connections will be blocked. Ensure that your firewall, such as UFW or firewalld, allows traffic on the new port number before testing the connection.
Can I enable both password and key-based authentication?
Yes, you can enable both by setting PasswordAuthentication yes and ensuring PubkeyAuthentication yes is present. However, this is less secure than key-only authentication. It is recommended to disable passwords once you have verified that key-based login works reliably for all users.
What happens if I make a typo in sshd_config?
A syntax error in sshd_config will prevent the SSH daemon from starting. If you are connected remotely, you will lose access to the server. Always use sudo sshd -t to validate the config before restarting the service, and keep a console or physical access available if possible.
Does changing the SSH port improve security?
Changing the port provides "security through obscurity" by reducing exposure to automated bot scans. It does not protect against targeted attacks, as determined attackers will scan all ports. Combine port changes with other hardening measures like fail2ban and key-based authentication for better results.