SSH Hardening for Dedicated Hosting

Securing a dedicated hosting environment is just as important as optimizing its performance. One of the most essential aspects of server security is protecting your SSH access. Without proper techniques, SSH can become a target for attackers. This guide will show you the most effective techniques for SSH Hardening for Dedicated Hosting.

At PerLod Hosting, we provide powerful and reliable dedicated hosting solutions designed for high performance and security. With the right SSH hardening strategies, you can ensure that your hosting environment remains fast, stable, and secure.

Let's dive into the guide steps.

Important safety note before we start: Always keep at least one active SSH session open while testing changes. If you lock yourself out, you will need console or provider recovery to fix it.

Prerequisites:

• You must have a working shell with sudo or root access.
• OpenSSH server (sshd) is installed on your Linux server.
• A second terminal or separate machine to test SSH connectivity.

Check that OpenSSH is installed and running on your server:

Check OpenSSH version:

Test OpenSSH configuration syntax before restart:

Once you are done, proceed to the following steps to start SSH Hardening for Dedicated Hosting.

The first step is to run the system and upgrade to fix known vulnerabilities. To do this, run the following command:

Always review the kernel updates; they may need reboots.

Because we want to limit root logins to improve accountability and reduce attack surface, you should not use the root user. You must create a user with sudo privileges.

To create the user, you can run the following command:

Add the user to the sudo group with the following command:

To verify sudo works, you can test with the commands below:

One of the most important techniques for hardening SSH for dedicated hosting is to use SSH key authentication.

It is recommended to use the "ed25519" key on your client because it is compact, secure, and fast. To generate the SSH key on your local machine, you can run the command below:

This command will create ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub.

Then, you must copy the public key you have generated on your local machine to the server. You can use the ssh-copy-id command to do this:

Another way is that you can manually add it to your server. On your server, run the following commands to append the public key to authorized_keys:

Note: We use ed25519 over RSA because it is smaller, safer, and efficient.

After you have confirmed that SSH key-based login works in a separate session, you can disable passwords and root logins for security.

To do this, open the sshd config file:

Set the following lines as shown below:

Then, reload the sshd to apply the changes:

You can also run the following command instead of editing the file manually:

Then, test and reload the SSH:

Disabling root and passwords is the most effective technique for SSH hardening.

At this step, you can limit which users can SSH into your server. You can use AllowUsers or AllowGroups to restrict SSH access.

From the sshd config file:

For example, you can only allow the sudo user you have created:

Or you can restrict to a group:

Then, test and reload the SSH:

When you connect to a server using SSH, your computer and the server need to agree on how to talk securely. They use things like:

• KEX (Key Exchange): How they agree on a secret key.
• Ciphers: How your messages get scrambled so nobody can read them.
• MACs (Message Authentication Codes): How they make sure nobody changes the messages while they travel.

By default, OpenSSH already uses Protocol 2, which is safe. But you can make it even more secure by telling SSH which modern and strong algorithms it should use.

Important Warning: If you make SSH too strict, old computers or tools that don’t understand these modern algorithms won’t be able to connect. That’s why you should test first and make sure your clients can still log in before applying these changes permanently.

You can use these modern algorithms in the sshd config file:

By default, SSH runs on port 22, which attackers constantly scan. You can change it to a non-standard port. This doesn’t make your server “unhackable,” but it reduces the noise from automated bots trying to break in.

You can limit the number of password attempts and login grace time. Also, you can be sure no one can log in with a blank password.

Open the sshd config file and modify these options:

Another option is to throttle connections (DoS Protection). This setting controls how many simultaneous new SSH connections are allowed.

From the sshd config file, modify:

After changes, test and reload SSH:

It is recommended to allow only required IPs and ports. You can use your server's firewall, like UFW and FirewallD, or your hosting provider's security group.

For example, if you change the SSH port to 2222, allow it through your firewall:

For your specific IP, you can use:

Then, reload the firewall:

For firewalld, you can use:

Note: If you want to lock access to specific IP ranges, add those rules. Always ensure your management IP is allowed before enabling a firewall.

As you must know, Fail2Ban watches auth logs and blocks IPs that exceed failed attempts. You can create a local override to avoid upgrades overwriting with the following command:

Check the SSH client status:

Verify logs in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL).

You can make your SSH logins much more secure by adding Two-Factor Authentication (2FA). It means you first log in with your password or key, then you also confirm your identity with a one-time code from an app or a hardware key.

Two methods to add 2AF:

• TOTP codes (Google Authenticator, Authy, etc.)
• Hardware keys (like YubiKey)

Warning: If you misconfigure 2FA, you might lock yourself out, so test carefully. Hardware security keys are preferred for enterprise-grade control.

For example, we want to set up Google Authenticator (TOTP):

Install the package with the command below:

For each user, run this (as that user):

It shows a QR code. Scan it with Google Authenticator on your phone. Save the backup codes somewhere safe.

Next, you must tell the system to require 2FA by editing /etc/pam.d/sshd file. Add this line at the top before other auth lines:

Make sure these are set in the /etc/ssh/sshd_config file:

Finally, reload SSH:

If you manage lots of servers, it is recommended not to copy keys everywhere. Instead, use an SSH Certificate Authority (CA). The CA can issue short-lived certificates that prove a user’s identity. It has easy revocation, shorter lifetimes, and no need to edit every server’s authorized_keys.

For a high-level process, create a CA keypair on a secure (offline) machine. Then, add the CA’s public key to the /etc/ssh/sshd_config file:

Next, sign user keys with:

This example makes a certificate valid for 52 weeks.

You must be sure all SSH login attempts are sent to your central log system, like rsyslog. You can use Auditd to track changes to critical files like /etc/ssh/sshd_config or ~/.ssh/authorized_keys. Also, use regular scans with tools like ssh-audit, Lynis, or OpenSCAP to detect weak settings.

Example Auditd rule which watches sshd_config:

Always protect private keys with a passphrase. You can use ssh-agent so you don’t need to retype passphrases constantly. Rotate keys if an employee leaves or on a set schedule. If using certificates, revoke them instead of editing every server.

Tip: GitHub’s docs on SSH agent and key management are a good reference.

Always keep a backup admin account in case your main account is locked. Remember to have out-of-band access, like your provider’s VNC or serial console.

When changing ports or firewall rules, keep the current session open until you’ve confirmed the new settings work.

Before editing, save a backup with:

Here is a starting point for a secure SSH setup. You can customize it for your environment.

Check config before reloading:

If no errors, then reload SSH:

That's it, you are done with SSH Hardening for Dedicated Hosting.

SSH hardening for dedicated hosting environment is one of the most essential steps in server security. By creating non-root administrative users, enforcing key-based authentication, disabling password logins, and implementing tools such as Fail2Ban and firewalls, you can reduce the risk of compromise.

Following the practices outlined in this guide will help ensure your dedicated hosting environment remains secure, stable, and accessible to authorized administrators.

If you value both performance and security, you can check our powerful and reliable dedicated hosting solutions.

We hope you enjoy this guide. Subscribe to our X and Facebook channels to get the latest guides and security tips.

For further reading:

Step-by-Step Linux Kernel Live-Patching

Implementation of Zero-Trust Architecture on Dedicated Server

Microsegmentation Setup in Linux Server