Guides
VNC over SSH on macOS: A Practical Guide
VNC over SSH gives macOS Screen Sharing a stronger outer layer: key-based access first, screen access second.
At a glance
- The viewer talks to a local VNC address while SSH carries the traffic to the Mac.
- The SSH host is the reachable Mac endpoint; the VNC address is usually localhost.
- The safest setup keeps the VNC service unavailable to the network directly.
The mental model
VNC over SSH sounds like two things glued together, but the model is clean. The remote viewer connects to a local address, such as localhost:5901. That local port is not the Mac screen service itself. It is the near side of an SSH tunnel.
The SSH tunnel reaches the Mac. At the far side of the tunnel, the Mac connects to its own screen service, often on localhost:5900. The viewer sees a normal VNC endpoint. The network sees SSH.
The fields that matter
Most connection mistakes come from mixing up the SSH side and the VNC side. The SSH host is the address that can reach the Mac: a LAN IP, a DDNS name, a public WAN endpoint, or a mesh VPN address. The SSH port is the port your gateway listens on.
The VNC address is different. When VNC lockdown is enabled, the VNC address should stay localhost because the Mac is meant to reach its own screen service from inside the tunnel. Entering the Mac LAN IP as the VNC target can defeat the loopback-only model and cause the connection to fail.
- SSH host: where the tunnel goes.
- SSH key: who is allowed to open the tunnel.
- VNC address: what the Mac dials after the tunnel lands.
- VNC password or Mac user: the screen-sharing layer after SSH is already open.
Why key restrictions matter
A normal SSH login can do too much if it is not constrained. For remote screen access, the key usually does not need shell access, SCP, SFTP, arbitrary forwarding, or agent forwarding. It needs one job: open the path required for the screen session.
That is where forced commands, permitopen-style constraints, and per-key origin scope become valuable. They turn the key from a general login credential into a narrowly described remote-access artifact.
The practical result
VNC over SSH gives you a familiar viewer experience without making the VNC port the thing the outside world can reach. You can keep using RealVNC, TightVNC, TigerVNC, MobaXterm, Remmina, AVNC, or Screens while the Mac-side path stays gated by SSH.
HearthGate packages that model into a Mac-native setup: generate the key, choose the scope, export the client material, and let the viewer connect through the secure path.
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