Remote Access Security
Why VNC Port 5900 Should Not Be Exposed to the Internet
Port 5900 is convenient for VNC, but convenience is not the same thing as a safe remote-access boundary. Here is why the screen port should stay behind SSH.
At a glance
- A directly reachable VNC port becomes a standing invitation for scans and password guessing.
- LAN-only exposure is still exposure when laptops, guests, IoT devices, and VPNs share the same network.
- A safer pattern is to keep VNC local and require SSH key possession before the screen service can be reached.
The problem is not VNC itself
VNC is a simple idea: a viewer connects to a screen service and displays the remote desktop. On macOS, Apple Screen Sharing uses a VNC/RFB-shaped path for screen access. That can be useful, especially when you need familiar viewers across Windows, iOS, Linux, FreeBSD, or another Mac.
The risk appears when the VNC port is treated as the first door. The default VNC port, 5900, is easy to remember and easy to scan. If it is reachable from the internet, it becomes part of the background noise of automated probing. If it is reachable from the LAN, it is still visible to every device that can sit on that network segment.
A screen port should not be the boundary
Remote screen access is high-impact access. Once the viewer is in, the user can see the desktop, interact with apps, and potentially reach secrets that were never designed to cross the network. That makes the boundary around the screen service more important than the screen service itself.
A better security posture is to require a stronger, narrower step before VNC is even reachable. SSH key authentication is well suited to that role. The SSH side can be limited by keys, origin scope, tunnel-only rules, idle timeouts, and logging. The VNC side can then remain local, behind that gate.
- Do not forward port 5900 from the router.
- Do not rely on a short VNC password as the first line of defense.
- Do not assume the LAN is trusted simply because it is local.
Why localhost changes the shape of the risk
When a VNC viewer reaches localhost through an SSH tunnel, the VNC service is no longer the public entry point. The remote user first proves possession of the SSH key, reaches the Mac through the SSH endpoint, and only then lets the Mac connect to its own local screen service.
That model reduces the exposed surface. The screen port can stay closed to the network while remaining usable to the SSH tunnel. An attacker on the same LAN does not get a direct VNC target. An internet scanner does not see port 5900. The visible entry point becomes SSH, where key-based controls and narrower policy are easier to apply.
Where HearthGate fits
HearthGate is built around this exact shape: keep Apple Screen Sharing on the Mac, but put the remote path behind SSH, restricted keys, connection packages, and optional firewall-enforced VNC lockdown. The goal is not to make VNC mysterious. The goal is to stop the VNC port from being the thing the network talks to first.
If you need remote screen access, port 5900 should be a local destination, not a public address. Own the path before you share the screen.
Want the Mac-side gateway for this model?
HearthGate packages secure VNC over SSH, restricted keys, firewall VNC lockdown, connection bundles, and session visibility into one native Mac app.
Explore HearthGate