SSH open to the whole internet draws constant scanning from the first hour. Putting admin access behind a private VPN shrinks that exposure: only clients inside the tunnel reach port 22, control panels and databases. The steps below work on any Linux server.
Why VPN plus SSH keys
- Smaller attack surface. Scanners never see the management ports.
- Two gates. The VPN user, then the SSH key.
- A stable allow-list. One dedicated VPN address is easier to trust in a firewall than a changing home connection.
- An easy audit statement: admin access only through a private tunnel.
Hardening checklist
- Provision Private VPN and enrol the admin devices only.
- On each server, allow SSH and panel ports from the VPN address and drop everything else.
- Use key-only SSH: disable password login and direct root login.
- Keep a ban tool such as fail2ban for services that must stay public, like web and mail.
- Document a break-glass route through the provider console, because a locked-down server needs a way back in.
- Revoke the user in the VPN on the day someone leaves.
Test the new rule from a second session before you close the old one. A mistyped firewall rule is the quickest way to lock yourself out.
Mistakes to avoid
| Mistake | Better |
|---|---|
| A non-standard SSH port as the only protection | Keys and a firewall; the port is optional |
| One shared VPN account for all admins | One named user each |
| IPv4 rules without IPv6 rules | Apply the same policy to both stacks |
| Panels left on public ports | Treat them like SSH |
Record who was enrolled, when profiles were revoked and which firewall objects use the VPN address. That trail matters in an audit. The first-day checklist is in security in the first 24 hours, and the team setup is in VPN setup for remote workers. Servers to protect: cloud and dedicated.
Frequently asked questions
Can I keep SSH public just in case?
You can, and you inherit constant scanning. VPN-only SSH with a console fallback is cleaner.
Does a dedicated VPN address matter?
Yes. A fixed address keeps the allow-list short and stable.
What about panel ports?
Treat them like SSH and keep them VPN-only where you can.
What if the VPN host fails?
Use the provider console. Write the steps down before you need them.
