LINUX • CYBERSECURITY • SSH

How to Harden SSH on Linux: Disable Root and Password Login

Secure your Linux server by disabling direct root login, requiring SSH key authentication, and restricting remote access with AllowUsers. Follow this step-by-step guide to apply the changes safely and avoid locking yourself out.

Author: Khurram Shahzad

Platform: Ubuntu, Debian, Rocky Linux

Technology: OpenSSH

Level: Intermediate

Time: 20–30 minutes

Last updated: October 16, 2026

Quick answer: how to harden SSH Create and test an SSH key for a non-root administrator account. Back up the SSH configuration, set PermitRootLogin no, PasswordAuthentication no, and AllowUsers youradmin, validate the configuration with sudo sshd -t, and then reload or restart the SSH service. Keep your existing session open until a new login has been verified.

Reduce Your Linux Server’s SSH Attack Surface

SSH is essential for remote administration, but allowing direct root access, password authentication, and unrestricted user access creates avoidable risks. A few carefully tested configuration changes can make access more controlled and easier to audit.

SSH
HARDENINGKEYS • USERS • ACCESS

Important: prevent administrator lockout Do not disable password authentication until you have successfully logged in using a key for an ordinary account with the required sudo privileges. Keep your current SSH connection open, confirm console or recovery access, and test the final configuration from a second terminal.

Disable Root Login

Use a named administrator account and elevate privileges with sudo.

Require SSH Keys

Disable password and keyboard-interactive authentication after testing key access.

Allow Approved Users

Use AllowUsers to restrict SSH logins to explicitly named accounts.

What Is SSH Hardening?

SSH hardening means configuring the Secure Shell service to reduce unnecessary access and make unauthorized login attempts more difficult. Instead of allowing anyone with a valid account and password to attempt a remote login, administrators can require cryptographic keys, prohibit direct root access, and define exactly which accounts may connect.

Setting	Purpose	Recommended value for this guide
`PermitRootLogin`	Controls direct SSH login as root.	`no`
`PubkeyAuthentication`	Enables public-key authentication.	`yes`
`PasswordAuthentication`	Controls password-based SSH authentication.	`no`
`KbdInteractiveAuthentication`	Controls keyboard-interactive authentication.	`no` for a key-only setup
`AllowUsers`	Limits SSH access to named users or matching patterns.	Only approved accounts

Important distinction Disabling root SSH login does not remove the root account or prevent authorized administrators from using sudo. Disabling password authentication for SSH also does not disable password use for every other service on the system.

Requirements and Safety Checks

A Linux server running OpenSSH Server.
A normal user account with the necessary administrative privileges.
A working SSH key pair and successful key-based login before password authentication is disabled.
Console access, hypervisor console access, cloud serial console, or another recovery method.
The correct SSH port and firewall rules for your environment.
Permission to administer the server and change its security policy.

The examples below use Ubuntu and Debian service names where appropriate, with alternatives for Rocky Linux, AlmaLinux, and other RHEL-based distributions. Commands and default configuration files can differ between distributions.

Step 1: Create a Non-Root Administrator

Use an individual named account instead of connecting directly as root. If you already have an administrator account with sudo privileges, use it and proceed to Step 2.

Create an administrator account on Ubuntu or Debian

sudo adduser youradmin
sudo usermod -aG sudo youradmin

Replace youradmin with your actual Linux username. On Ubuntu and Debian, adding the account to the sudo group typically grants administrative privileges.

For Rocky Linux, AlmaLinux, or other RHEL-based systems

sudo useradd -m youradmin
sudo passwd youradmin
sudo usermod -aG wheel youradmin

Use the distribution’s documented administrative group and sudo policy. The wheel group commonly grants sudo access when the system’s sudoers configuration enables it.

Verify privileges before continuing Open a separate session as the new user and confirm that sudo -v succeeds. Do not disable root login until you have a tested administrator account and a working recovery method.

Step 2: Configure and Test SSH Keys

Public-key authentication lets a client prove possession of a private key without sending the private key to the server. Keep the private key on your trusted client, protect it with a passphrase, and install only its public key on the server.

Generate an Ed25519 key on your client

ssh-keygen -t ed25519 -C "youradmin@trusted-client"

Accept the suggested file path or choose an appropriate location. Set a strong passphrase to protect the private key if the file is copied or stolen.

Install the public key on the server

ssh-copy-id youradmin@server-ip

Replace the username and server address. If your server uses a custom port, use ssh-copy-id -p 2222 youradmin@server-ip and replace 2222 with the actual port.

If ssh-copy-id is unavailable, add the contents of your public key file to the user’s ~/.ssh/authorized_keys file using an authorized method.

Test key-based login in a new terminal

ssh youradmin@server-ip

Authenticate using the key and its passphrase if prompted. If you need more diagnostic information, run:

ssh -v youradmin@server-ip

Confirm that the connection authenticates with publickey and that the account can run the required administrative commands.

Do not skip this step A key file existing on your computer does not prove that the server accepts it. Confirm a successful new login before you change any authentication settings.

For more detailed instructions, read our SSH key-based authentication guide.

Step 3: Back Up the SSH Configuration

OpenSSH normally reads server settings from /etc/ssh/sshd_config and may also load configuration snippets from /etc/ssh/sshd_config.d/. Make a backup before changing anything.

Back up the main configuration

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.vmorecloud-backup

Keep this backup secure and do not overwrite it until you have a known-good replacement. If your system uses configuration snippets, inspect those as well:

sudo ls -la /etc/ssh/sshd_config.d/

If the directory does not exist, continue with the main configuration file. Do not create configuration files in a directory that your SSH service does not include.

Understand configuration precedence On Ubuntu and some Debian-based systems, included files may be read before the main configuration settings. OpenSSH generally uses the first obtained value for most directives. Adding a setting at the bottom of the main file may therefore not override a value supplied by an earlier included file. Always verify the effective settings with sshd -T.

Step 4: Disable Direct Root Login

Direct root login makes the most privileged account a remote authentication target. Set PermitRootLogin no to prohibit SSH login as root, including key-based root login.

Open the SSH daemon configuration

sudo nano /etc/ssh/sshd_config

Locate the existing PermitRootLogin directive and set it to:

PermitRootLogin no

Edit the existing directive rather than leaving conflicting duplicates. If an included configuration file defines the value first, adjust the appropriate file or snippet after checking your distribution’s configuration order.

Expected result The server rejects direct SSH logins as root. Administrators should connect using their own accounts and use sudo for authorized privileged operations.

Step 5: Disable Password Authentication

Once key-based access has been confirmed, disable SSH password authentication. For a key-only policy, also disable keyboard-interactive authentication unless your environment specifically requires it for another approved authentication method.

Set the authentication directives

In the effective SSH server configuration, ensure these directives are set:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

PubkeyAuthentication yes enables public-key authentication. PasswordAuthentication no disables password authentication through SSH, while KbdInteractiveAuthentication no disables keyboard-interactive authentication.

Check your authentication dependencies Do not disable keyboard-interactive authentication blindly if your organization relies on PAM-based one-time passwords, MFA prompts, or another approved interactive authentication method. Confirm the intended authentication design first.

These directives govern SSH authentication; they do not remove local passwords or automatically change authentication policy for console logins and unrelated services.

Step 6: Restrict Access with AllowUsers

The AllowUsers directive creates an explicit list of user accounts permitted to log in through SSH. When it is configured, users not matching the list are denied SSH access, even if their accounts otherwise exist on the server.

Allow only approved accounts

For example, to permit SSH access only for an administrator and a designated operations account:

AllowUsers youradmin opsuser

Replace these example usernames with real, approved accounts. Separate usernames with spaces. Do not include the root account if direct root SSH access is prohibited.

Optional: restrict a user to a known source address

OpenSSH also supports a user-and-host pattern. For example:

AllowUsers youradmin@192.0.2.10 opsuser

This is an example using the documentation-only IP address 192.0.2.10. Replace it with the real source address if you intend to use this restriction. Host matching depends on the address and host information available to the server.

AllowUsers can lock out legitimate users Every SSH account that must continue working needs to match the policy. Include any automation or service accounts that genuinely require SSH access, and test them before applying the restriction. An account’s presence in AllowUsers does not grant it a valid key or sudo privileges.

Example: combined hardening policy

For a simple server with one approved administrator, the intended directives would look like this:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers youradmin

These are configuration directives, not shell commands. Put them in the configuration file that actually controls the effective values on your system.

Step 7: Validate and Apply the Configuration

Never restart SSH immediately after an unverified configuration edit. First run the configuration test, inspect effective values, and make sure you have recovery access.

Validate the SSH configuration syntax

sudo sshd -t

No output normally means the configuration passed the syntax test. If you receive an error, correct the file or directive before proceeding. On systems where the executable is not in your default path, use its full path, such as /usr/sbin/sshd -t.

Reload or restart the SSH service

For Ubuntu and Debian, use:

sudo systemctl reload ssh

If reload is not supported in your environment, or your operational procedure requires a restart, use the appropriate service command. For Rocky Linux, AlmaLinux, and many RHEL-based systems:

sudo systemctl reload sshd

If reload is unsupported, use sudo systemctl restart sshd. Check the service status afterward:

sudo systemctl status ssh --no-pager

On RHEL-based systems, replace ssh with sshd in the status command.

Keep your current session open Do not close your existing working SSH session until you have successfully established a second connection using an approved account and verified that your administrative access still works.

Step 8: Verify the Effective Settings

Use OpenSSH’s effective-configuration output to confirm that the daemon is using your intended values. This matters because included configuration snippets, distribution defaults, or other directives can affect the final result.

Check the key hardening directives

sudo sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|allowusers) '

Confirm that the effective output shows permitrootlogin no, pubkeyauthentication yes, passwordauthentication no, and kbdinteractiveauthentication no. The allowusers line should contain the accounts you intentionally approved.

If a directive is missing from the output, or the value differs, inspect the complete output and the included configuration files. A syntax test alone does not prove the policy is correct.

Test a new key-based connection

ssh youradmin@server-ip

Confirm the intended account can connect and use sudo. From a separate test session, verify that root login and password-only SSH authentication are refused.

For example, from a trusted client, you can test that password authentication alone is unavailable:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password youradmin@server-ip

With the intended key-only policy in effect, this connection should fail to authenticate. Perform this test only after confirming a working key-based connection and recovery access.

Verification complete The server should accept SSH connections only from permitted accounts using the authentication methods your policy allows. Review service logs and conduct a final login test before considering the change complete.

Additional SSH Security Measures

Use a firewall

Limit the SSH port to trusted management networks or VPN addresses where possible. Confirm the active firewall rules before changing them remotely.

Keep OpenSSH updated

Apply supported operating-system and OpenSSH security updates through your normal patch-management process.

Use individual accounts

Avoid sharing administrator credentials. Separate accounts improve accountability and make access revocation easier.

Protect private keys

Use a strong passphrase, restrict access to private-key files, and revoke public keys when devices or users no longer need access.

Consider MFA or hardware-backed keys

For sensitive systems, consider an approved multi-factor design or hardware-backed SSH keys. Test compatibility with your authentication policy.

Monitor login activity

Review authentication logs, failed login attempts, and unexpected access. Forward relevant events to your central logging platform when available.

Check authentication logs

On Ubuntu or Debian, inspect the SSH service logs with:

sudo journalctl -u ssh --since "1 hour ago"

On Rocky Linux, AlmaLinux, or other RHEL-based systems, use:

sudo journalctl -u sshd --since "1 hour ago"

For another layer of protection, see our guide to configuring SSH on a different port. A non-default port may reduce routine automated noise, but it is not a substitute for strong authentication and access controls.

Troubleshooting SSH Hardening

Permission denied (publickey)

Check the username, public key in authorized_keys, home-directory permissions, SSH directory permissions, and server logs. Use ssh -vvv youradmin@server-ip from the client to identify the failure.

Still prompted for a password

Verify the effective values using sudo sshd -T. Inspect files in /etc/ssh/sshd_config.d/ and any relevant authentication settings.

AllowUsers blocks an administrator

Use console or recovery access to correct the allowed-user list. Check spelling, account names, source restrictions, and whether other approved users or automation accounts need SSH access.

SSH fails to restart

Run sudo sshd -t and read the error carefully. Fix invalid directives or file syntax before attempting another reload or restart.

Effective values do not match

Check the main configuration and included snippets. OpenSSH generally uses the first value obtained for most directives, so a later line may not override an earlier value.

Lost remote access

Use the hypervisor console, cloud console, serial console, or another approved recovery method. Restore the known-good configuration, validate it, and retest access before applying changes again.

When investigating, distinguish between a configuration syntax problem, a service problem, a network/firewall issue, and an authentication-policy rejection. They require different fixes.

Frequently Asked Questions

Should I disable root SSH login on Linux?

For most administratively managed Linux servers, setting PermitRootLogin no is a strong default. Use a named administrator account and elevate privileges with sudo. Confirm recovery access before making the change.

Is it safe to disable SSH password authentication?

Yes, when the intended users have working public-key authentication and you have verified access and recovery procedures. Do not disable passwords before confirming that your administrator can log in using a key.

What does AllowUsers do in SSH?

AllowUsers limits SSH logins to usernames or patterns listed in the directive. Other accounts may be denied SSH access even if they exist on the system. Carefully include every account that legitimately needs SSH access.

Does AllowUsers replace Linux permissions or sudo?

No. It controls which accounts may authenticate through SSH. Linux account permissions, group membership, sudo policy, file permissions, and application access controls continue to apply.

Should I disable keyboard-interactive authentication too?

For a simple key-only SSH policy, administrators commonly set KbdInteractiveAuthentication no alongside PasswordAuthentication no. If your organization uses PAM-based MFA or another interactive authentication method, review its design before disabling it.

Can I apply SSH hardening without restarting the server?

You do not normally need to reboot Linux. After validating the configuration, reload the SSH service if supported. Keep a working session open and test a new connection afterward.

Does changing the SSH port make my server secure?

A non-default port can reduce some automated scanning noise, but it does not replace key-based authentication, access restrictions, software updates, firewall controls, or monitoring.

How can I check whether SSH password login is disabled?

Run sudo sshd -T and check the effective passwordauthentication value. Also inspect keyboard-interactive authentication and test a new connection using the intended account and authentication policy.

Conclusion: Harden SSH Without Locking Yourself Out

Hardening SSH is an important step in securing a Linux server. Disable direct root login with PermitRootLogin no, require public-key authentication by disabling password-based access, and use AllowUsers to restrict SSH access to approved accounts. Back up the configuration, check the effective settings, validate the syntax, and test a new connection before closing your existing session.

Final SSH hardening checklist

Create and test a non-root administrator account.
Verify key-based login from a new client session.
Back up the SSH configuration and inspect included snippets.
Set PermitRootLogin no.
Set PasswordAuthentication no and review keyboard-interactive authentication.
Set AllowUsers to the approved account list.
Run sudo sshd -t and inspect effective values.
Reload or restart the correct SSH service.
Test permitted and prohibited logins while recovery access remains available.
Review firewall rules, updates, keys, and authentication logs.

Keep Learning with VMoreCloud

Build a stronger Linux security baseline with practical tutorials covering SSH, networking, cloud infrastructure, Windows Server, and virtualization.

Browse All Tutorials →

Sources & Further Reading

👤 About the Author

Khurram Shahzad

Hybrid Cloud & Virtualization Engineer

Hybrid Cloud & Virtualization Engineer specializing in VMware, Microsoft Azure, AWS, Windows Server, Microsoft 365, Linux, networking, backup and disaster recovery. I share practical technical guides, infrastructure projects and insights to help IT professionals build and manage modern IT environments through VMoreCloud.

🖥️ VMware 🔷 Azure ☁️ AWS 🪟 Windows Server 🐧 Linux 🛡️ Cybersecurity 🔗 Networking

📄

VMoreCloud

Cloud, IT and technical tutorials

View all articles →

Learn | Build | Share

☁️ VMoreCloud|Tech Knowledge for a Better Tomorrow

IT • Cloud • Virtualization • Security • Open Source

Technical note: OpenSSH directives, service names, configuration include order, and authentication defaults vary by operating system and version. Verify the effective settings on your server before applying changes. Perform these steps only on systems you are authorized to administer.