How to harden SSH by disabling password authentication

Disabling password authentication is a critical step in securing your server against automated brute-force attacks. This guide applies to Ubuntu, Debian, AlmaLinux, Rocky, and CentOS Stream. You will update the SSH daemon configuration to require public keys for every login attempt.

Prerequisites

• Root access or sudo privileges on a Linux server (Ubuntu 24.04, Debian 12, AlmaLinux 9, Rocky 9, or CentOS Stream 9).
• An SSH public key already generated and copied to your server (usually in ~/.ssh/authorized_keys).
• Ability to connect via SSH key authentication before making changes.
• Ensure you have a backup of your current configuration before editing.

Step 1: Create a backup of the SSH configuration

Before modifying any system files, create a backup of the current sshd_config. This ensures you can restore the original settings if a mistake occurs. Run the following command to copy the file to a safe location in /root.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

You will see a success message indicating the file has been copied. Keep this backup safe until you confirm the new settings work correctly.

Step 2: Edit the SSH daemon configuration file

Open the sshd_config file using a text editor like nano or vim. You need to locate the line that controls password authentication and change its value to 'no'. Search for the directive that starts with 'PasswordAuthentication'.

sudo nano /etc/ssh/sshd_config

Once the file is open, use the search function (Ctrl+W in nano) to find the line containing 'PasswordAuthentication'. If the line is commented out with a hash symbol (#) at the beginning, remove the hash to uncomment it. Change the value from 'yes' to 'no'. If the line does not exist, add it manually near the bottom of the file.

PasswordAuthentication no

Ensure there are no spaces around the equals sign or the value. Save the file and exit the editor (Ctrl+O, Enter, then Ctrl+X in nano).

Step 3: Disable empty passwords

Even if password authentication is disabled, the server might still allow login with an empty password. You must explicitly disable this feature to prevent weak authentication vectors. Locate the line starting with 'PermitEmptyPasswords' and set it to 'no'.

PermitEmptyPasswords no

Like the previous step, uncomment the line if it is commented out. If the line is missing, add it to the configuration file. This change ensures that no user can log in without a password, even if the system allows password authentication for other users.

Step 4: Disable root login via password

It is best practice to prevent direct root login via SSH to reduce the attack surface. Locate the line 'PermitRootLogin' and set it to 'prohibit-password'. This allows root login only via SSH keys, blocking password-based root access.

PermitRootLogin prohibit-password

Alternatively, you can set this to 'no' if you do not need root access at all. If you choose 'no', ensure you have a non-root user with sudo privileges to perform administrative tasks. Save the file after making these changes.

Step 5: Restart the SSH service

After editing the configuration file, you must restart the SSH daemon for the changes to take effect. Running the service command will stop the current daemon and start a new one with the updated settings. This action applies immediately without requiring a server reboot.

sudo systemctl restart sshd

For systemd-based systems like Ubuntu 24.04, AlmaLinux 9, and Rocky 9, the service name is 'sshd'. On older CentOS or RHEL systems, you might see 'sshd' or 'ssh'. The command will return to the prompt without output if the restart is successful.

Verify the installation

Check the status of the SSH service to ensure it is running and listening on port 22. Use the systemctl command to view the active state. You should see 'active (running)' in the output.

sudo systemctl status sshd

You will see a summary line indicating the service is active. If you are unsure about your own login method, try logging in from a different machine using your SSH key. If you can log in, the configuration is correct. If you are locked out, restore the backup file immediately.

Troubleshooting

If you cannot log in after making these changes, you may have locked yourself out. Here are common errors and how to fix them.

Service failed to start

If the SSH service fails to start, check the logs for syntax errors. The syntax of the configuration file is validated at startup. If an error is found, the service will not launch.

sudo journalctl -u sshd -n 20

Look for lines mentioning 'bad configuration option' or 'syntax error'. If a typo is found in the config file, restore the backup and correct the error.

Cannot log in with SSH key

If you cannot log in with your key, the authorized_keys file might be missing or have incorrect permissions. Ensure the file exists in your home directory and has the correct permissions.

chmod 600 ~/.ssh/authorized_keys

Also, ensure the .ssh directory has permissions of 700. If the file is missing, you must copy your public key from your local machine to the server's ~/.ssh/authorized_keys file before restarting the service.

Permission denied errors

If you see permission denied errors, check the permissions on the /etc/ssh/sshd_config file. It should be readable by the root user and not writable by others.

sudo chmod 600 /etc/ssh/sshd_config

Run the command to set the correct permissions. If the service still fails, restore the backup configuration file and restart the service again. Always test changes in a safe environment or ensure you have a console access method like VNC or IPMI before disabling password authentication.