Secure remote access to a server comes down to five questions: What is exposed to the internet? Who and what is allowed in? Is the traffic encrypted end to end? Can access be limited to specific servers and ports? Can you see what happened afterwards? The approach you choose (public SSH, a bastion, a gateway VPN or a mesh VPN) answers each of them differently.
This guide goes through the questions in order, then shows how to set up access with Peerlify.
1. Minimise what's exposed
Every service listening on a public address is something to patch, monitor and defend. The most effective control is not to have one.
- Public SSH/RDP: the service itself is exposed. RDP on the open internet in particular has a long history of being targeted.
- Bastion host: one hardened host is exposed instead of many.
- Gateway VPN: the VPN endpoint is exposed.
- Mesh VPN or reverse tunnel: servers connect outbound, so nothing on the server's network listens publicly.
If you can't reduce exposure to zero, reduce it to one well-maintained component.
2. Authenticate people and devices
A password, or one SSH key copied to five laptops, tells you nothing about which machine is connecting. Stronger setups bind access to:
- a person, through your identity provider (single sign-on, MFA), so offboarding happens in one place;
- a device, through a key that's generated on that device and never leaves it, so a lost laptop can be cut off without touching anyone else.
3. Encrypt end to end
SSH and RDP encrypt their own sessions. Many internal services, such as databases, metrics endpoints and admin panels, don't, or are configured not to. Remote access that wraps all traffic in an encrypted tunnel between the two endpoints protects those as well.
"End to end" matters when there's anything in the middle. If a VPN gateway or relay decrypts and re-encrypts traffic, it can read it. If it only forwards ciphertext between two endpoints that hold the keys, it can't. How encrypted remote access works explains the difference.
4. Scope access per server and port
"On the VPN" shouldn't mean "can reach everything". Good access control:
- names servers by role or tag, not by IP ranges you maintain by hand;
- grants people or groups access to specific ports (22 for admins, 5432 for the app team);
- is enforced somewhere the client can't bypass;
- starts from deny, or at least makes the default obvious.
5. Keep a record
When something goes wrong you'll want to know who changed access and who connected to what. At minimum, log administrative changes. Ideally, log connections as well.
How the approaches compare
| Public SSH | Bastion | Gateway VPN | Mesh VPN | |
|---|---|---|---|---|
| Public exposure | Every server | One host | VPN endpoint | None on the server side |
| Device identity | SSH keys, if managed | SSH keys, if managed | Varies | Built in |
| Encrypts non-SSH traffic | No | No | Yes | Yes, end to end |
| Per-server access rules | sshd and firewall config | Bastion config | Varies | Policy rules |
| Works behind CGNAT | No | Bastion must be reachable | Gateway must be reachable | Yes |
These are properties of the architectures, not of specific products.
Setting it up with Peerlify
Peerlify is a mesh VPN. Here's how it answers the five questions, and what it doesn't do.
Exposure. The client on each server connects outbound to Peerlify's control plane and relays, and to its peers. There's no port to forward. That works behind NAT and CGNAT too.
People and devices. People sign in with GitHub, Google, Microsoft, Apple or your own OpenID Connect provider. Each device creates its own key pairs on first start, and only the public keys leave it. Servers enroll with auth keys, which can be single-use, expiring, pre-tagged or ephemeral. Networks can require an admin to approve each new device.
Encryption. Traffic between two devices is encrypted end to end with AES-256-GCM, using session keys derived on the two devices in a handshake modelled on the Noise IK pattern. When traffic goes through a Peerlify relay, the relay forwards ciphertext.
Scope. The access policy is a JSON document. Rules name users, groups, roles, tags or devices, with ports and protocols, and the device receiving a connection enforces them. Policies can include tests that run before every save, and every saved version can be restored. Note that a new network starts with an allow-all rule: replace it before you add people.
Record. The console's audit log records administrative changes. Business and Enterprise plans add activity logs of connections between devices, kept for 90 days.
Offboarding. Remove a device or member in the console and online peers drop it within seconds. Removing someone from your identity provider alone doesn't end an enrolled device's session; do both.
Limits. Every server you want to reach needs the client (Windows, macOS or Linux); Peerlify doesn't route to other machines on a server's LAN. The private network carries IPv4.
To try it, follow the quickstart, or the server-focused walk-through in how to access a server behind NAT. For SSH specifically, see SSH without port forwarding.