A VPS can run a fast WordPress site, a mail service, a development environment, or internal business tools. But it is also a public server, and SSH is usually the first service attackers test. Secure VPS SSH access is not about adding obscure settings for their own sake. It is about making unauthorized access difficult while keeping routine administration dependable for the people who actually maintain the server.
For small businesses and independent administrators, the practical risk is usually not a targeted movie-style attack. It is automated scanning, password guessing, exposed credentials, missed updates, or an old contractor account that was never removed. A sensible SSH setup addresses those common failures first.
Start With Separate Administrative Accounts#
Do not use the root account for normal SSH work. Root has unrestricted authority, so one incorrect command, compromised key, or exposed session has maximum impact. Create a named user for each person who needs server access, then grant administrative privileges through `sudo` only where required.
This approach gives you accountability and makes offboarding simple. When a developer, agency, or employee no longer needs access, remove that user or their SSH key. You do not need to change a shared root password and hope no one saved it elsewhere.
On Ubuntu or Debian, a typical starting point is:
“`bash adduser adminuser usermod -aG sudo adminuser “`
Use a meaningful account name rather than a generic shared login. If several people administer the VPS, each should have an individual account. Shared access feels convenient until you need to determine who changed a configuration, rotated a certificate, or installed an unfamiliar package.
For automation, create a dedicated service account with only the permissions the job needs. A deployment process that requires unrestricted sudo access deserves closer review. Limiting it may take extra setup time, but it sharply reduces the damage from a leaked deployment key.
Use SSH Keys Before Disabling Passwords#
Password authentication is a frequent target because bots can try common credentials continuously. SSH keys are stronger and more practical once configured. The private key stays on the administrator’s computer, while the server stores the matching public key in the user’s `~/.ssh/authorized_keys` file.
Generate a modern key pair on your local computer. Ed25519 is a good default for most current systems:
“`bash ssh-keygen -t ed25519 -a 100 -C “admin@company” “`
Protect the private key with a passphrase. A passphrase matters because a copied or stolen laptop should not automatically become a server-access device. An SSH agent can remember the key during a work session, so this protection does not need to create daily friction.
Install the public key for the new administrative user, then test it in a separate terminal before changing any server authentication settings:
“`bash ssh adminuser@your-server-ip “`
Keep the existing root or provider console session open while testing. This is a small operational habit with major value. If a typo in permissions or configuration prevents login, you still have a working path to fix it.
After key-based login works, update `/etc/ssh/sshd_config` or a distribution-specific file under `/etc/ssh/sshd_config.d/`. Exact defaults vary by operating system and hosting image, so check the active configuration before replacing settings blindly. The intent is generally:
“`text PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes “`
Validate the configuration before reloading SSH:
“`bash sudo sshd -t sudo systemctl reload ssh “`
Do not disable passwords until every administrator has tested their own key. If team members rely on separate devices, such as an office workstation and a secured backup laptop, register appropriate keys for each device rather than copying one private key between machines.
Limit Who Can Reach SSH#
Keys protect authentication, but reducing exposure is another useful layer. Configure your VPS firewall so it allows only services the server actually provides. For a typical web server, that may be SSH, HTTP, and HTTPS. Database ports, caching services, control panels, and development tools should not be publicly open unless there is a clear operational need.
With UFW on Ubuntu, the basic pattern is straightforward:
“`bash sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable “`
If your office has a stable public IP address, restrict SSH to that address at the provider firewall or host firewall. This is highly effective because unwanted traffic never reaches the SSH service. The trade-off is access flexibility. Remote staff, travel, home internet connections, and mobile backups can make fixed-IP rules difficult to manage.
For teams with changing locations, a VPN or private network can be a better answer than opening SSH to the entire internet. It adds one more component to maintain, but it can simplify access control across several servers. A provider console should remain available as a break-glass option, protected by strong account security and multi-factor authentication.
Changing SSH to a nonstandard port can reduce noise from basic scans, but it is not a primary security control. Attackers can scan all ports. Use a different port only if it fits your operations, and do not treat it as a replacement for keys, firewall rules, and updates.
Apply Least Privilege to SSH and Sudo#
A secure configuration should distinguish between a server owner, a support technician, a deployment account, and an application process. They should not all have the same access by default.
You can use SSH settings such as `AllowUsers` or `AllowGroups` to explicitly define which accounts may connect. This is useful on servers with multiple local users or software-created accounts that should never receive remote access. For example:
“`text AllowGroups sshadmins “`
Pair that with a dedicated `sshadmins` group and add only approved administrators. Be careful when making access-control changes remotely. Confirm that your current account belongs to the allowed group before reloading the service.
Sudo deserves the same attention. Giving a user full sudo access is appropriate for a trusted system administrator, but not necessarily for a contractor who only needs to restart PHP-FPM or review application logs. A narrowly scoped sudo rule can reduce risk, though overly complex rules can become hard to audit. Keep the policy understandable and document why exceptions exist.
Keep the Server Patchable and Observable#
The best SSH configuration cannot compensate for an unpatched operating system or an exposed provider account. Apply security updates on a regular schedule, especially for OpenSSH, the kernel, web server packages, and management tools. Automatic security updates can work well for many small VPS deployments, but test how they fit your application and reboot policy. Kernel updates may require a planned restart.
Review authentication logs periodically. On many Linux distributions, successful and failed SSH activity appears in `/var/log/auth.log` or the system journal. Look for new keys, unexpected successful logins, repeated failures, and sudo activity outside normal maintenance windows.
Tools that slow repeated password guessing can reduce log noise and opportunistic abuse. Fail2ban is a common option, but it should be configured carefully. A mistaken rule can lock out a legitimate administrator after a few failed attempts. SSH keys and firewall restrictions are more dependable core controls; automated bans are supporting protection.
Set up basic alerts for disk space, service failures, backup status, and unusual login events. Security incidents become much harder to resolve when the server is already out of disk space and backups have been failing silently for weeks. For WordPress and WooCommerce operators, this is especially relevant: a server problem can quickly become a storefront outage, failed orders, or lost administrative time.
Plan for Key Loss and Staff Changes#
A key-based setup is only secure if you can manage its lifecycle. Keep an inventory of who has access, which public keys belong to which devices, and what emergency recovery path exists. The inventory can be a simple protected operations document. It does not need enterprise tooling to be useful.
Remove keys immediately when a device is lost, an employee leaves, or a contractor completes work. Avoid the tempting shortcut of putting several people on one shared key. You lose accountability and make revocation disruptive.
Also protect local private keys. Full-disk encryption, operating system updates, screen locking, and a password manager or secure hardware-backed key store all reduce the chance that a local device becomes the weak point. For higher-risk administrative environments, hardware security keys that support SSH can provide added protection against private-key extraction.
Before making major SSH changes, confirm that you can access the VPS through the hosting provider’s out-of-band console. Test this recovery route before an incident, not during one. It is the practical safety net when a firewall rule, SSH configuration change, or local key problem blocks normal access.
Secure administration should support the work your server performs rather than obstruct it. Start with named users, passphrase-protected SSH keys, no direct root login, a narrow firewall, and a tested recovery route. Once those controls are routine, maintaining a VPS becomes less about reacting to login noise and more about keeping the applications that support your business available and productive.