DEV Community

Ramer Labs
Ramer Labs

Posted on

7 Tips for Hardening SSH Access on Linux Servers in Environments

#linux #security #devops #tutorial

Introduction

Secure shell (SSH) is the de‑facto remote‑access protocol for Linux servers. While it’s powerful, a mis‑configured SSH daemon is a common entry point for attackers. This guide walks you through seven practical steps to lock down SSH access, suitable for SREs managing production workloads.

1. Enforce Public‑Key Authentication Only

Password‑based logins are trivially brute‑forced. Generate a key pair on your workstation:

ssh-keygen -t ed25519 -C "yourname@company.com"
Enter fullscreen mode Exit fullscreen mode

Copy the public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your‑server.com
Enter fullscreen mode Exit fullscreen mode

Then edit /etc/ssh/sshd_config to disable passwords:

PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
Enter fullscreen mode Exit fullscreen mode

Reload the daemon:

sudo systemctl reload sshd
Enter fullscreen mode Exit fullscreen mode

2. Disable Root Logins

Allowing direct root access dramatically widens the attack surface. In the same sshd_config file, add:

PermitRootLogin no
Enter fullscreen mode Exit fullscreen mode

If you need elevated privileges, use sudo after logging in with a regular user account.

3. Restrict Users and IPs

Limit which accounts can open SSH sessions. The AllowUsers directive accepts a space‑separated list of user@host patterns:

AllowUsers alice@10.0.0.0/24 bob@example.com
Enter fullscreen mode Exit fullscreen mode

For tighter network control, combine this with firewall rules (e.g., ufw or iptables) to only accept connections from trusted subnets.

4. Change the Default Port (Optional but Helpful)

Bots hammer the default port 22. Moving SSH to a non‑standard port reduces noise:

Port 2222
Enter fullscreen mode Exit fullscreen mode

Remember to update your firewall to allow the new port and inform legitimate users of the change.

5. Deploy Fail2Ban for Automated Banning

Fail2Ban watches log files and bans IPs that show malicious signs. Install and enable it:

sudo apt-get install fail2ban   # Debian/Ubuntu
sudo systemctl enable fail2ban
Enter fullscreen mode Exit fullscreen mode

Create a custom jail for SSH (/etc/fail2ban/jail.d/ssh.conf):

[sshd]
enabled = true
port    = 22,2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
Enter fullscreen mode Exit fullscreen mode

Restart Fail2Ban:

sudo systemctl restart fail2ban
Enter fullscreen mode Exit fullscreen mode

6. Enable Two‑Factor Authentication (2FA)

Adding a time‑based one‑time password (TOTP) layer stops attackers even if they somehow obtain a private key. Install libpam-google-authenticator:

sudo apt-get install libpam-google-authenticator
Enter fullscreen mode Exit fullscreen mode

Run the setup for each user:

google-authenticator
Enter fullscreen mode Exit fullscreen mode

Edit /etc/pam.d/sshd and add:

auth required pam_google_authenticator.so nullok
Enter fullscreen mode Exit fullscreen mode

Finally, tell SSH to require both public‑key and keyboard‑interactive auth:

AuthenticationMethods publickey,keyboard-interactive
Enter fullscreen mode Exit fullscreen mode

7. Keep the SSH Daemon Patched

Vulnerabilities in OpenSSH are patched regularly. Automate updates with your package manager or a configuration‑management tool:

# Debian/Ubuntu
sudo apt-get update && sudo apt-get upgrade -y openssh-server

# RHEL/CentOS
sudo yum update -y openssh-server
Enter fullscreen mode Exit fullscreen mode

If you run a fleet of servers, consider using Ansible or Terraform to enforce a baseline version across the board.

Quick Checklist

  • [ ] Generate and distribute Ed25519 keys
  • [ ] Set PasswordAuthentication no
  • [ ] Disable PermitRootLogin
  • [ ] Define AllowUsers with host restrictions
  • Change Port to a non‑standard value
  • [ ] Install and configure Fail2Ban for SSH
  • [ ] Enable TOTP 2FA via PAM
  • [ ] Schedule regular OpenSSH updates

Conclusion

Hardening SSH is a series of low‑effort, high‑impact steps. By enforcing key‑based auth, restricting who can log in, adding automated bans, and layering 2FA, you dramatically reduce the risk of unauthorized access. Remember to treat SSH configuration as living code—review it whenever you add new users or change network topology.

For more hands‑on tutorials and best‑practice guides, check out https://lacidaweb.com.

Top comments (0)