SSH Security Best Practices for Production Servers

SSH is the primary way Linux servers are administered. It is also the most common attack vector — automated bots scan the internet constantly, attempting brute-force logins against SSH on port 22. A default SSH configuration is a liability. This guide covers the essential hardening steps that every production server should have in place.

These practices range from quick wins (disabling password auth) to advanced techniques (certificate-based authentication and jump hosts). Implement them in order of priority for maximum security impact.

1. Disable Password Authentication

The single most impactful change you can make. Password authentication is vulnerable to brute-force attacks, credential stuffing, and weak passwords. Key-based authentication is immune to all of these.

Before disabling password auth, ensure you have at least one SSH key configured and tested for your account. Lock yourself out by disabling passwords before adding a key, and you will need physical or console access to recover.

2. Use Strong SSH Keys

Not all SSH keys are created equal. Use Ed25519 keys — they are shorter, faster, and more secure than RSA. If you must use RSA (legacy compatibility), use at least 4096 bits.

Always use a passphrase on your private key. Without one, anyone who gains access to your laptop or workstation has immediate access to all your servers. Use ssh-agentto avoid typing the passphrase repeatedly.

3. Disable Root Login

Never allow direct root login via SSH. Use a regular user account and escalate withsudo when needed. This provides an audit trail of who logged in and what they did.

4. Change the Default Port

Moving SSH off port 22 is not a security measure by itself — it is security through obscurity. But it dramatically reduces noise from automated scanners. Most bots only try port 22.

Use your ~/.ssh/config file to remember custom ports per host, so you do not have to type -p 2222 every time.

5. Install fail2ban

fail2ban monitors log files for failed login attempts and automatically bans offending IP addresses using firewall rules. It is the standard defense against brute-force attacks.

Check banned IPs with sudo fail2ban-client status sshd. For cloud environments, consider using cloud-native security groups in addition to fail2ban for defense in depth.

6. Restrict Access with AllowUsers and AllowGroups

Limit which users can log in via SSH. This prevents service accounts, application users, and other non-administrative accounts from being used for SSH access.

7. Use Jump Hosts (Bastion Servers)

In production environments, internal servers should not be directly accessible from the internet. Use a hardened bastion (jump) host as the single entry point, and tunnel through it to reach internal hosts.

The bastion host should have the strictest hardening: no unnecessary software, key-only auth, fail2ban, and full audit logging. Restrict it to a single purpose — no other services should run on it.

8. Additional Hardening Options

Also consider using SSH certificates instead of authorized_keys files for large teams. With certificates, a central CA signs user keys, and servers trust the CA — no need to distribute public keys to every server. Tools like Vault, step-ca, or Teleport make this manageable.

Quick Reference: sshd_config Hardening Checklist