Limit SSH connection attempts on a Linux VPS

Repeated SSH connection attempts keep showing up in your Linux VPS server logs? The right response is to shrink the attack surface without locking yourself out. This guide walks through a progressive method on a virtual private server: verify administrator access, harden authentication, watch the logs, then automate blocking with Fail2ban if your distribution supports it.

Before you start: keep a rescue access path

Keep an SSH session already open while you make changes and make sure you have a console access provided by your hosting provider. Note the administrator account name, the SSH port actually in use, the IP address you are connecting from and the domain name possibly attached to the VPS. A misdirected firewall rule or ban can cut off your legitimate connection.

This precaution applies to an Ubuntu, Debian or any other Linux distribution VPS. It also applies if the machine hosts a web server, a MySQL database, Apache, scripts or a control panel: SSH security must stay separate from the configuration of those applications. Also see our guide on the first security settings for a dedicated server and the one on diagnosing an unreachable VPS.

Read the logs before blocking anything

Start by identifying the service that records SSH connections on your system. On a machine using systemd, journalctl lets you filter messages from the SSH service. Depending on the distribution, the service may be named ssh or sshd. On other installs, events may also be written to an authentication file.

Look for repeated failures, the targeted users and the source addresses. A series of failures is not proof that an account has been compromised: it mainly signals that a rate-limiting policy is worth putting in place. Also check that the partition holding the logs is not running out of disk space. For a complementary administration method, see our guide on Docker on a VPS.

Harden SSH authentication

The most important measure is to use an SSH key protected by a passphrase wherever your environment allows it. Test the new key in a second session before considering disabling password authentication. Do not remove the only access method until the replacement has been validated.

Also avoid direct root logins when your administration policy calls for a named account with privilege elevation via sudo. The exact settings depend on your distribution and your operating model. After any SSH configuration change, check the syntax and then reload only the service concerned. Changing the port can reduce log noise, but it is not an authentication mechanism by itself.

Check the firewall and ports

Before adding a rule, list the services you actually need: SSH for administration, HTTP and HTTPS for a web server, DNS if the machine handles that role, or your application's ports. An open port does not mean a service is properly secured, and a closed port can make a website, an API or a game server unreachable.

If you use UFW or another firewall, first allow your SSH access, test the rule from a second session, then check the firewall status. Do not blindly apply a configuration meant for a shared host, a web hosting plan or a Plesk panel to a VPS that does not run the same services. Document every rule and remove access you no longer need.

Automatically limit connection attempts

Fail2ban can watch the logs, count failures within a time window and temporarily add an address to a ban action. This protection does not replace SSH keys, updates or a properly defined network rule. It must be configured with understandable values: ban duration, tolerated number of failures and observation period.

Start with a conservative policy, explicitly allow your administration addresses where relevant, then watch the Fail2ban logs. Do not copy a configuration found at random: the filter name, the log path and the service manager all change between systems. Your distribution's documentation remains the reference for these details.

Check the VPS resources

Saturating RAM, CPU or storage can complicate connection analysis and delay security services. Check memory usage, the available storage on the SSD or virtual disk, and the CPU load when you look into a spike of attempts. A web server, a MySQL database, backups and scheduled scripts share the same resources as SSH.

A VPS is a virtual server with resources allocated within a cloud hosting infrastructure. Its flexibility lets you administer a Linux system without managing the physical server directly, but bandwidth, storage and memory remain resources to watch. Several virtual servers can have different purposes: do not mix the rules of a test VPS, a production private server and a dedicated server.

Plan maintenance and recovery

Keep a backup of the SSH configuration and regularly check that your backups are restorable. A backup does not protect against a bad rule in real time, but it makes recovery after a configuration mistake easier. For an important service, document the network dependencies, the IP address, the DNS, the ports and the console access procedure.

High availability, redundancy or several servers can meet different operational needs, but they do not replace robust SSH authentication. Size the VPS according to the traffic and services actually used instead of opening extra access without control.

Verify after every change

Open a new connection from your administration machine, confirm it works, then check the events it produces. Also check that the ban expires as expected and that a legitimate address can be removed from the list if needed. Keep a copy of the validated configuration and document the console recovery procedure.

If the problem is rather a blocked remote port, use our guide to diagnose a blocked RDP port. For game servers, keep the SSH port clearly separate from the ports your application uses and see our guide to securing a game server.

SSH attempt limiting checklist

• A rescue session or console is available.
• A working SSH key has been tested in a second session.
• Failures have been observed in the right log.
• The administrator account uses a consistent sudo policy.
• The firewall exposes only the necessary services.
• The ban policy is progressive and documented.
• Your administration address cannot be banned by mistake.
• Operation has been verified after reloading the service.