DEV Community

Ramer Labs
Ramer Labs

Posted on

7 Tips for Securing SSH Access on Linux Servers for Production

#linux #security #devops

Introduction

Secure shell (SSH) is the de‑facto way to manage Linux servers, but a mis‑configured SSH daemon can become the weakest link in your production stack. As an SRE, you need a repeatable checklist that you can run on every new instance, whether it lives on a bare‑metal box, a cloud VM, or a container host. Below are seven practical steps that tighten SSH without breaking the workflow of your engineering team.

1. Enforce Key‑Based Authentication Only

Passwords are easy to guess, brute‑force, or phish. Switch the server to accept only public‑key authentication.

# On the client, generate a strong key pair if you don’t have one already ssh-keygen -t ed25519 -a 100 -C "your.email@example.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.example.com
Enter fullscreen mode Exit fullscreen mode

Then edit /etc/ssh/sshd_config:

# /etc/ssh/sshd_config PasswordAuthentication no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Enter fullscreen mode Exit fullscreen mode

Reload the daemon:

sudo systemctl reload sshd
Enter fullscreen mode Exit fullscreen mode

2. Restrict Users and Groups

Only allow the accounts that truly need remote shell access. Use the AllowUsers or AllowGroups directives to whitelist.

# Allow only devops engineers and the automation user AllowGroups devops ssh‑automation
Enter fullscreen mode Exit fullscreen mode

Create the groups and add members:

sudo groupadd devops sudo usermod -aG devops alice sudo usermod -aG devops bob
Enter fullscreen mode Exit fullscreen mode

3. Change the Default Port (Optional but Helpful)

Moving SSH off port 22 reduces noise in your logs and thwarts opportunistic scans. Pick a high, non‑standard port (e.g., 4242).

Port 4242
Enter fullscreen mode Exit fullscreen mode

Remember to update your firewall rules accordingly.

4. Harden the Cipher Suite

Modern ciphers provide better performance and security. Force the use of ed25519 keys and strong MACs.

# Preferred key exchange algorithms KexAlgorithms curve25519‑sha256@libssh.org,diffie‑hellman‑group‑exchange‑sha256 # Strong ciphers only Ciphers chacha20‑poly1305@openssh.com,aes256‑gcm@openssh.com # MAC algorithms MACs hmac‑sha2‑512-etm@openssh.com,hmac‑sha2‑256-etm@openssh.com
Enter fullscreen mode Exit fullscreen mode

5. Deploy Fail2Ban for Brute‑Force Protection

Fail2Ban monitors log files and bans IPs that show malicious signs. Install and enable a ready‑made SSH jail.

sudo apt‑get install fail2ban # Debian/Ubuntu sudo yum install fail2ban # RHEL/CentOS
Enter fullscreen mode Exit fullscreen mode

Create /etc/fail2ban/jail.local:

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

Restart the service:

sudo systemctl restart fail2ban
Enter fullscreen mode Exit fullscreen mode

6. Enable Two‑Factor Authentication (2FA)

For privileged accounts, add a time‑based one‑time password (TOTP) layer using google-authenticator.

sudo apt‑get install libpam-google-authenticator google-authenticator # Run as the target user
Enter fullscreen mode Exit fullscreen mode

Edit /etc/pam.d/sshd to include:

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

And enable ChallengeResponseAuthentication:

ChallengeResponseAuthentication yes
Enter fullscreen mode Exit fullscreen mode

7. Audit and Log SSH Activity

Enable verbose logging to capture every login attempt, key usage, and command execution. This is invaluable for post‑mortem investigations.

LogLevel VERBOSE
Enter fullscreen mode Exit fullscreen mode

Consider shipping logs to a centralized system (e.g., ELK or Loki) for correlation with other security events.

Quick Checklist

  • [ ] Generate and distribute ed25519 keys.
  • [ ] Set PasswordAuthentication no.
  • [ ] Whitelist users/groups via AllowUsers/AllowGroups.
  • [ ] Move SSH to a non‑standard port (optional).
  • [ ] Restrict ciphers, MACs, and KexAlgorithms.
  • [ ] Install and configure Fail2Ban.
  • [ ] Enable 2FA for privileged accounts.
  • [ ] Set LogLevel VERBOSE and forward logs.

Running this checklist on every new host gives you a consistent security baseline while keeping the developer experience smooth.

Conclusion

Hardening SSH is a low‑cost, high‑impact win for any production environment. By automating the steps above—ideally via Ansible or a similar IaC tool—you eliminate human error and free up time for higher‑value work. If you’re looking for more detailed guides on Linux hardening or need help integrating these practices into your CI/CD pipeline, check out https://lacidaweb.com for practical resources and community support.

Top comments (0)