0 SSH Security Best Practices for Linux Administrators - kevwells.com

SSH Security Best Practices for Linux Administrators

by

Secure Shell (SSH) is the standard tool for remote administration of Linux systems. In practice, it is also one of the most common weaknesses I encounter when reviewing environments. Misconfigurations are frequent, and attackers actively exploit them. Hardening SSH is one of the most effective early steps in strengthening infrastructure security.

1. Why SSH Security Matters

  • Attack surface: SSH is almost always enabled and is constantly scanned on the internet.

  • Credential theft: Old or poorly managed keys, and password logins, are still common.

  • Privilege escalation: Weak SSH access often gives attackers the foothold they need to escalate to root.

  • Compliance: Frameworks such as ISO27001, CIS benchmarks, and GDPR all expect secure remote access controls.

2. Use SSH Keys Instead of Passwords

My recommendation is to enforce key-based access everywhere.

  • Generate strong keys:

     
    ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

    • ed25519 is efficient and secure.

    • -a 100 strengthens resistance against brute-force attacks.

  • RSA keys should be at least 3072 bits.

  • Private keys must always be protected with a passphrase.

  • Keys should be rotated. In some audits I have seen the same key in use for a decade, which is unacceptable.

3. Disable Root Login

Direct root login should always be disabled:

 
PermitRootLogin no

  • Administrators log in with personal accounts, then escalate with sudo.

  • This ensures accountability in the logs.

4. Restrict Password Authentication

Once keys are in place, disable password logins:

 
PasswordAuthentication no

  • This prevents brute force attacks.

  • If passwords must remain for transition, restrict them to bastion hosts.

5. Limit Which Accounts Can Log In

Limit SSH access to a specific group:

 
AllowGroups admins

This prevents unnecessary or unused accounts from attempting access.

6. Configure Idle Timeouts

Idle sessions left open for hours are a risk. Configure timeouts in sshd_config:

 
ClientAliveInterval 300
ClientAliveCountMax 2

This drops idle sessions after around 10 minutes.

7. Change Default Port (optional)

Changing the port reduces scanning noise:

 
Port 2222

This is not a substitute for other controls, but it cuts log noise and brute force attempts.

8. Rate-limit Authentication Attempts

Use Fail2ban or firewall rules to limit brute force attempts. Example Fail2ban jail:

 
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600

This blocks IPs after repeated failed logins. I often see hundreds of automated login attempts per day on public servers — throttling removes the noise.

9. Enforce Strong Ciphers and Protocols

Legacy algorithms are still widely enabled. Remove them. Example secure config:

 
Protocol 2
KexAlgorithms curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512,hmac-sha2-256

This enforces only modern ciphers and protocols.

10. Audit and Monitor SSH Access

  • Set LogLevel VERBOSE to record key fingerprints on login.

  • Forward logs (/var/log/auth.log or /var/log/secure) to a central SIEM such as Splunk or ELK.

  • Key checks include:

    • Multiple failed attempts from a single IP.

    • Unexpected geographic locations.

    • Logins outside business hours.

11. Add MFA for SSH

Multi-factor authentication strengthens critical systems:

  • TOTP codes with libpam-google-authenticator.

  • YubiKey or similar hardware tokens via pam_u2f.

I have deployed both approaches for clients where SSH was a high-value target.

12. Regular Maintenance

SSH security is not a one-time task. Ongoing actions include:

  • Patching OpenSSH regularly.

  • Auditing authorized_keys files for stale entries.

  • Revoking access when staff leave.

  • Documenting and reviewing access quarterly.

Conclusion

In my experience, weak SSH setups are still one of the most frequent issues I encounter in Linux environments. Attackers expect to find them, and too often they do.

By enforcing key-based authentication, disabling root login, restricting accounts, and auditing access, administrators can close down this entry point. No Linux system should be considered production-ready until SSH hardening has been completed.

Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.

With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.

Contact for Contract Assignments

No related posts.