Why your cloud servers should stop answering strangers on port 22

If a cloud server answers SSH or PostgreSQL requests from the open internet, every scanner on the network gets a free invitation. For a 1–10 person team that still needs fully self-hosted access to those machines, the cleaner starting point is a self-hosted NetBird deployment. NetBird builds a WireGuard private network with a control plane you host yourself, then uses identity-aware policies and device posture checks to decide which laptops and service identities may reach which servers.

That design only works if identity is solid. Run a self-hosted OIDC provider next to NetBird and require phishing-resistant MFA. After login, NetBird should not hand every authenticated user a path to every host. Policies should deny by default and open only the paths the team actually needs. SSH still owns usernames, keys or certificates, and command rights. PostgreSQL still owns roles and grants. NetBird’s job is the network door.

The identity provider authenticates the user. NetBird’s management plane registers peers, distributes keys and policy, and coordinates signaling. Peers try to form a direct WireGuard tunnel. If that fails because of NAT or firewall limits, an encrypted relay path remains available. Traffic does not become readable on the relay just because it could not go direct. NetBird explains the components at docs.netbird.io/about-netbird/how-netbird-works and the self-host path at docs.netbird.io/selfhosted/selfhosted-guide.

From there, policy does the real work. According to NetBird’s access-control documentation, administrators can limit connectivity by source group, destination group, protocol, and port. Posture checks can add device conditions before that access is granted. In a small production setup, that usually means developers may reach staging on TCP 22, production operators may reach production on TCP 22, database administrators may reach PostgreSQL on TCP 5432, and CI may reach only the ports required for deploy jobs. No other combination should work.

Closing the public listeners is the last step, not the first. Create the groups, write the narrow policies, confirm production posture rules, keep host firewalls and native audit logs, and prove that a break-glass route still works if NetBird or the identity system is unavailable. Only then remove public exposure of ports 22 and 5432. Offboarding follows the same discipline: disable the person in the identity provider and revoke NetBird access at the same time.

Teams often compare this approach with Teleport and Headscale. Teleport is the stronger product when the requirement is short-lived credentials, command auditing, or session recording for SSH and databases. Headscale can run a self-hosted control plane for Tailscale clients, but it is not a complete substitute for NetBird’s first-party policy and posture model. If the problem is private-network least privilege under full self-hosting, NetBird is the primary fit. If the problem is privileged-session control, Teleport is the stronger fit. Many security-minded teams will eventually use NetBird for reachability and Teleport for the recorded privileged work that happens after the connection is allowed.

Wikimedia Commons/by Dsimic