When you rent a dedicated server, you get full root access — which also means SSH is the front door to your entire infrastructure. Unlike shared hosting, there's no provider-managed layer sitting between an attacker and your operating system. If SSH is left on default settings, it becomes the single easiest way for automated bots and attackers to get in.
This checklist walks through the practical steps for hardening SSH on a UK dedicated server, why each step matters, and where the responsibility sits between you and your hosting provider.
Why SSH Security Matters More on a Dedicated Server
On a dedicated server, you are the system administrator. There's no shared security layer absorbing misconfigurations for you. Every internet-facing dedicated server with SSH open on port 22 will see automated login attempts within hours of going live — this is a constant, background reality of running public IP infrastructure, not something specific to any one provider.
The good news: most SSH compromises come from a small set of preventable weaknesses — default ports, password-only logins, and root access left open. Fixing these closes the majority of the attack surface.
Who's Responsible: You or Your Provider?
This depends on the type of server you're running.
Unmanaged dedicated servers give you full root access and full responsibility. SSH hardening, firewall rules, and OS patching are entirely on you.
Managed dedicated servers typically include baseline OS hardening and patching from the provider's support team, with the server owner still controlling application-level access.
If you're not sure which model fits your team, our guide on managed vs unmanaged dedicated servers breaks down exactly where that line sits.
The SSH Hardening Checklist
Work through these in order. Each one closes a specific, common attack path.
1. Disable direct root login
Root is the most targeted username on any Linux server because attackers already know it exists. Create a separate administrative user with sudo privileges, then disable direct root SSH access by setting PermitRootLogin no in sshd_config.
2. Switch to key-based authentication
SSH keys are far harder to brute-force than passwords. Generate an SSH key pair, install the public key on the server, and confirm key-based login works before disabling passwords.
3. Disable password authentication entirely
Once key-based login is confirmed working, set PasswordAuthentication no. This alone eliminates brute-force password guessing as a viable attack method.
4. Change the default SSH port
Moving off port 22 won't stop a targeted attacker, but it dramatically cuts down the noise from automated scanners that only check default ports. Pick an unused high port and update your firewall rules to match.
5. Restrict SSH access by IP address
If your team connects from a fixed office IP, VPN, or a small set of known locations, use firewall rules or sshd_config's AllowUsers/Match Address directives to only permit SSH from those ranges.
6. Use fail2ban or an equivalent intrusion prevention tool
Fail2ban watches your logs and automatically bans IPs after repeated failed login attempts. It's lightweight, works well alongside key-based auth, and stops slow, distributed brute-force attempts that a firewall whitelist alone might miss.
7. Set an idle session timeout
Configure ClientAliveInterval and ClientAliveCountMax so idle SSH sessions disconnect automatically. This limits the window of exposure if a session is left open on an unattended machine.
8. Limit which users can use SSH
Use AllowUsers or AllowGroups in sshd_config to explicitly list who is permitted to connect over SSH, rather than leaving it open to every account on the system.
9. Keep OpenSSH and the OS patched
SSH vulnerabilities are rare but serious when they surface. Apply OS and OpenSSH security updates promptly rather than batching them into infrequent maintenance windows.
10. Monitor and log SSH access
Review /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/AlmaLinux/Rocky Linux) periodically, or forward logs to a monitoring stack, so unusual login patterns don't go unnoticed.
11. Consider two-factor authentication (2FA) for SSH
For servers handling sensitive data or payment systems, adding 2FA via tools like Google Authenticator PAM modules provides a second layer beyond your SSH key.
Combining SSH Hardening with Network-Level Protection
SSH hardening secures the login itself, but it works best as part of a wider defence layer. A dedicated hardware firewall filtering traffic before it reaches your server, combined with DDoS mitigation at the network edge, reduces the volume of malicious traffic your SSH daemon ever has to deal with in the first place. We cover the network side of this in more detail in how to stop a DDoS attack on a dedicated server.
Choosing an OS That Supports Clean SSH Management
The operating system you choose affects how straightforward SSH hardening is. On eServers UK dedicated servers, customers can choose from AlmaLinux, Ubuntu LTS, Rocky Linux, or Windows depending on their stack. AlmaLinux and Rocky Linux both use firewalld and SELinux by default, giving you an extra policy layer on top of SSH-level hardening, while Ubuntu LTS pairs well with ufw for straightforward firewall management alongside sshd_config changes.
Running a UK dedicated server with full root access means SSH security starts with you. Whether you're managing it yourself or want it handled as part of a managed hosting plan, getting these fundamentals right early avoids most of the automated attacks hitting exposed servers every day.
Frequently Asked Questions (FAQ)
Should I disable SSH entirely if I don't use it often?
If you manage your server through a control panel like cPanel, DirectAdmin, or Plesk and rarely need shell access, you can restrict SSH to specific IPs rather than leaving it open to the internet, and only enable broader access when you need it.
Is changing the SSH port actually worth it?
Yes, as a noise-reduction measure. It won't stop a determined, targeted attacker, but it removes your server from the vast majority of automated, default-port scans running constantly across the internet.
What's the single most important step on this list?
Disabling password authentication in favour of SSH keys. It removes brute-force login attempts as a viable attack method entirely, regardless of what port SSH runs on.
Does a managed dedicated server need this checklist too?
Managed plans usually cover baseline hardening, but it's worth confirming with your provider exactly what's included — application-level SSH access for your own admin accounts is often still your responsibility.
