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.

Prerequisites for SSH Hardening for Dedicated Hosting

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:

sudo systemctl status sshd #RHEL-Based
sudo systemctl status ssh  #Debian-Based

Check OpenSSH version:

sshd -v 2>&1 | head -n1

Test OpenSSH configuration syntax before restart:

sudo sshd -t

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

1. Update Dedicated Hosting System

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

sudo apt update && sudo apt upgrade -y  #Debian-Based
sudo dnf update -y                      #RHEL-Based

Always review the kernel updates; they may need reboots.

2. Create a Sudo User in Dedicated Server

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:

sudo adduser username

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

sudo usermod -aG sudo username   #Debian-Based
sudo usermod -aG wheel username  #RHEL-Based

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

su - username
sudo -v

3. Use SSH Key Authentication (Strongly Recommended)

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:

ssh-keygen -t ed25519 -a 100 -C "[email protected]"

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:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@your.server.ip

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:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA… your_comment' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

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

4. Disable Password Authentication After SSH Key Setup

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:

sudo nano /etc/ssh/sshd_config

Set the following lines as shown below:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes          #keep PAM if your distro relies on it for sudo/2FA.
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Then, reload the sshd to apply the changes:

sudo systemctl reload sshd

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

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config

Then, test and reload the SSH:

sudo sshd -t
sudo systemctl reload sshd

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

5. Restrict SSH Access in Dedicated Server

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:

sudo nano /etc/ssh/sshd_config

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

AllowUsers username

Or you can restrict to a group:

AllowGroups sshusers

Then, test and reload the SSH:

sudo sshd -t
sudo systemctl reload sshd

6. Disable or Restrict SSH Weak Algorithms and Protocol Settings

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:

KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

7. Reduce Attack Surface: Change SSH Port and Control Max Attempts

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:

Port 2222
MaxAuthTries 3
LoginGraceTime 30s
PermitEmptyPasswords no

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:

MaxStartups 10:30:60

After changes, test and reload SSH:

sudo sshd -t
sudo systemctl reload sshd

8. Allow Only Required IPs and Ports for SSH Security

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:

sudo ufw allow 2222/tcp

For your specific IP, you can use:

sudo ufw allow from your-ip to any port 2222 proto tcp

Then, reload the firewall:

sudo ufw reload

For firewalld, you can use:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

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.

9. Use Fail2Ban to Block Brute-Force SSH Attempts

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:

sudo tee /etc/fail2ban/jail.d/ssh.local > /dev/null <<'EOF'
[sshd]
enabled = true
port = 2222
filter = sshd
maxretry = 5
bantime = 3600      #ban for 1 hour
findtime = 600      #10 minutes window
EOF

Check the SSH client status:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

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

10. Add Two-Factor Authentication (2FA) To Secure SSH Logins

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:

sudo apt install libpam-google-authenticator -y

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

google-authenticator

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:

auth required pam_google_authenticator.so nullok

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

UsePAM yes
ChallengeResponseAuthentication yes

Finally, reload SSH:

sudo systemctl reload sshd

11. SSH Certificates and Centralized Authentication (For Scaling)

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:

TrustedUserCAKeys /etc/ssh/ca.pub

Next, sign user keys with:

ssh-keygen -s /path/to/ca -I identity -n username -V +52w user.pub

This example makes a certificate valid for 52 weeks.

12. SSH Logging, Auditing, and Detection

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:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_changes

13. Maintain Secure SSH Keys and Rotate Them

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.

14. SSH Backup and Emergency Access Plan

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:

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

Example Hardened sshd_config File for a Secure SSH Setup

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

# Basic
Port 2222
Protocol 2
AddressFamily inet    # IPv4 only; use 'any' or 'inet6' if needed

# Authentication
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# User restrictions
AllowUsers username
# or AllowGroups sshusers

# Timeouts and limits
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 2

# Connection throttling
MaxStartups 10:30:60
# PerSourceMaxStartups 2:30:10   # if supported

# Keys & algorithms (test clients)
HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

# Logging & auditing
SyslogFacility AUTH
LogLevel VERBOSE

# Misc
AllowTcpForwarding no
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Check config before reloading:

sudo sshd -t

If no errors, then reload SSH:

sudo systemctl reload sshd

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

FAQs

Conclusion

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