Secure remote access is a cornerstone of modern system administration. While OpenSSH is the de‑facto standard for encrypted terminal sessions, a default installation leaves plenty of room for attackers to exploit. This guide walks you through configuring a hardened SSH server on any modern Linux distribution, balancing security with usability. By the end, you’ll have a robust setup that resists brute‑force attacks, limits exposure, and follows best‑practice hardening techniques.
What You’ll Need
- A Linux server (Ubuntu, Debian, CentOS, Fedora, or similar) with root or sudo privileges.
- Access to the server via an existing SSH session or console.
- Basic familiarity with the command line and text editors (nano, vim, or your favorite).
- A secondary, trusted machine to test the new configuration before you lock yourself out.
Step 1: Update Your System and Install OpenSSH
Before tweaking anything, ensure the underlying OS and OpenSSH package are up to date. Outdated libraries often contain known vulnerabilities.
“`bash
# Update package index
sudo apt update # Debian/Ubuntu
sudo dnf check-update # Fedora
sudo yum check-update # CentOS/RHEL
# Upgrade installed packages
sudo apt upgrade -y
sudo dnf upgrade -y
sudo yum update -y
# Install (or reinstall) OpenSSH server
sudo apt install -y openssh-server # Debian/Ubuntu
sudo dnf install -y openssh-server # Fedora
sudo yum install -y openssh-server # CentOS/RHEL
“`
Step 2: Backup the Original Configuration
Never edit the live configuration without a fallback. Copy the original file and note its location (/etc/ssh/sshd_config).
“`bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup$(date +%F)
“`
Step 3: Harden Authentication Settings
OpenSSH offers many authentication methods. We’ll keep public‑key authentication (the most secure) and disable password logins, root login, and unused authentication mechanisms.
Open the config file with your preferred editor:
“`bash
sudo nano /etc/ssh/sshd_config
“`
Make the following changes (add if missing, comment out the opposite):
Port 22→ change to a non‑standard port (e.g.,Port 2222). This reduces automated scans.Protocol 2(ensure it’s set; protocol 1 is obsolete).PermitRootLogin no(prevent direct root logins).PubkeyAuthentication yes(ensure public‑key auth is enabled).PasswordAuthentication no(disable password‑based logins).ChallengeResponseAuthentication no(turn off keyboard‑interactive).UsePAM no(optional, but if you rely on PAM for other services, keep ityesand ensure other hardening steps are in place).
Save and exit the editor.
Step 4: Restrict User Access
Limit which accounts may log in via SSH. This reduces the attack surface.
In the same sshd_config file, add:
AllowUsers alice bob– replace with the usernames you actually need.- Alternatively, use
AllowGroups sshusersand add users to that group:sudo groupadd sshusers && sudo usermod -aG sshusers alice.
Step 5: Enable Key‑Based Authentication
If you haven’t already generated an SSH key pair, do so on your client machine:
“`bash
ssh-keygen -t ed25519 -C “your_email@example.com”
“`
Copy the public key to the server (replace alice and your_server_ip):
“`bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub alice@your_server_ip -p 2222
“`
Verify that you can log in without a password:
“`bash
ssh -p 2222 alice@your_server_ip
“`
If the login succeeds, you’re ready to disable password authentication (already done in Step 3). Remember to keep a backup of your private key in a secure location.
Step 6: Harden the Cipher Suite and MACs
Modern OpenSSH defaults are already strong, but you can explicitly restrict algorithms to avoid legacy ones that might be vulnerable.
Add the following lines to sshd_config:
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.comKexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
These choices favor performance and strong security while dropping outdated algorithms.
Step 7: Set Up Rate Limiting with Fail2Ban
Even with a non‑standard port, brute‑force attempts will happen. Fail2Ban monitors log files and bans IPs that exceed a threshold.
Install and configure:
“`bash
sudo apt install -y fail2ban # Debian/Ubuntu
sudo dnf install -y fail2ban # Fedora
sudo yum install -y epel-release && sudo yum install -y fail2ban # CentOS/RHEL
“`
Create a local jail configuration to protect SSH:
“`bash
sudo bash -c ‘cat > /etc/fail2ban/jail.local <<EOF
[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 5
bantime = 3600
findtime = 600
EOF'
“`
Restart the service:
“`bash
sudo systemctl restart fail2ban
“`
Step 8: Test and Reload the SSH Service
Before you close your current session, test the new configuration in a separate terminal. This prevents accidental lock‑out.
“`bash
# Test syntax – will exit with a non‑zero code if there are errors
sudo sshd -t
# Reload without dropping existing connections
sudo systemctl reload sshd
“`
Now open a new terminal and attempt to connect using the new port and key. If it works, you can safely close the old session.
Common Mistakes to Avoid
1. Changing the port without updating firewall rules. If ufw, firewalld, or iptables still block the new port, you’ll be locked out. Add a rule before restarting SSH.
“`bash
sudo ufw allow 2222/tcp # UFW example
sudo firewall-cmd –add-port=2222/tcp –permanent && sudo firewall-cmd –reload # firewalld
“`
2. Disabling password authentication before copying your public key. Always verify key‑based login works first.
3. Leaving PermitRootLogin yes or AllowUsers empty. Both effectively allow any local account to SSH in.
4. Editing sshd_config without backing it up. A typo can prevent the daemon from starting. The ssh -t test catches this early.
5. Forgetting to restart or reload the service. Changes won’t take effect until you reload.
Tips and Tricks
• Use a jump host (bastion). Keep the hardened server behind a dedicated gateway that only allows SSH from known IPs.
• Enable two‑factor authentication. Install google-authenticator and add AuthenticationMethods publickey,keyboard-interactive to require both a key and a TOTP code.
• Log every login attempt. Add LogLevel VERBOSE to see usernames and IPs in /var/log/auth.log (or /var/log/secure on RHEL‑based systems).
• Restrict SSH to specific IP ranges. If you have a static office IP, add a firewall rule that only allows that range to the SSH port.
Frequently Asked Questions
Can I keep the default port 22 and still be secure?
Yes, but using a non‑standard port adds “security through obscurity” which reduces noise from automated scanners. It’s not a substitute for proper hardening, but it helps.
What if I need to allow SFTP access for a user?
SFTP runs over the same SSH daemon. Ensure the user’s shell is set to /usr/lib/openssh/sftp-server or use Subsystem sftp internal-sftp in sshd_config. You can also create a chroot jail for added isolation.
How do I recover if I lock myself out?
If you lose access, use the server’s console (e.g., via your cloud provider’s web console) to revert sshd_config to the backup you created. Then restart the service.
Conclusion
Hardening SSH on Linux is a series of small, deliberate steps that together create a formidable barrier against unauthorized access. By updating software, enforcing key‑based authentication, limiting users, tightening cryptographic choices, and adding automated intrusion‑prevention tools like Fail2Ban, you dramatically raise the cost of an attack. Remember to test each change, keep backups, and maintain a regular audit schedule. With this guide, your server’s remote access will be both secure and reliable—exactly what modern sysadmins need.
