How to secure SSH access

Quick answer: Secure SSH by switching to key-based authentication, disabling password logins and root access, limiting which users may log in, and adding Fail2ban. Edit /etc/ssh/sshd_config, apply the settings below and restart the SSH service — but keep your current session open until you confirm the new login works.

Overview

SSH is the main door into a Linux server and the most brute-forced service on the internet. Password logins are the weak point: bots try millions of combinations around the clock. Keys are immune to guessing, so moving to keys plus a few config lines removes almost the entire attack surface.

Before you start

• An SSH key pair installed and tested (how to set up SSH keys).
• A second terminal with a working root or sudo session — do not close it until you verify the changes.
• KVM Console access in the Client Area as a fallback.

Step-by-step guide

1. Open the SSH daemon config:

   nano /etc/ssh/sshd_config

2. Set the key hardening options:

   PasswordAuthentication no
   PermitRootLogin no
   PubkeyAuthentication yes
   MaxAuthTries 3
   LoginGraceTime 30

3. Optionally restrict logins to specific accounts:

   AllowUsers deploy admin

4. Restart SSH:

   systemctl restart ssh      # Ubuntu/Debian
   systemctl restart sshd     # AlmaLinux/Rocky

5. From a NEW terminal, confirm you can still log in with your key before closing the old session.
6. Add Fail2ban so repeated failures get banned automatically.

Common issues

• Locked out: use the KVM Console on your service page, log in locally and revert the config.
• Key refused: check permissions — ~/.ssh must be 700 and authorized_keys 600, owned by the user.
• Settings ignored: some distros load overrides from /etc/ssh/sshd_config.d/ — check files there too.

When to contact support

If both SSH and the KVM Console are unavailable, or you see signs of a successful intrusion in the logs (how to read auth logs), open a support ticket.

Frequently asked questions

Are SSH keys really safer than a strong password?

Yes. A key has vastly more entropy than any memorable password, is never typed or reused across services, and cannot be brute-forced remotely the way password logins can.

What if I lock myself out while changing SSH settings?

Open the KVM Console on your service page in the Cloud2Y Client Area — it works like a local monitor and keyboard, so you can log in and revert the SSH configuration safely.

Should I also change the SSH port?

It is optional. A non-standard port cuts automated scan noise in your logs but adds no real security, so treat it as a comfort measure after keys, root-login and firewall hardening.

Related articles

• How to set up SSH keys
• How to disable root SSH login
• How to change the SSH port
• How to install Fail2ban

Need a hand? Contact Cloud2Y support →