Topic hub
Secure Mac remote access
A practical map for reaching a Mac from Windows, iOS, Linux, FreeBSD, Android, or another Mac while keeping VNC behind SSH, keys scoped, logs visible, and the remote-access path under your control.
See the Mac-side gatewayDo not expose VNC first
The screen port should stay local. SSH should be the network entry point.
Keys should match the job
A screen key should not automatically become a broad shell key.
Reachability is not policy
A VPN or mesh route can reach the Mac. The Mac still needs a clear gateway posture.
Make the safe path repeatable
Scripts, packages, logs, revocation, and restore behavior matter after setup.
Start here
The core guides
These notes explain the model before the product pitch: why VNC should stay local, how SSH changes the boundary, and where mesh VPNs such as Tailscale fit.
Who Benefits from HearthGate? Mac Remote Access Use Cases for 2026
From creative studios and Mac mini homelabs to local AI boxes, consultants, education labs, and small IT teams: these are the scenarios where a secure Mac gateway matters.
Read guideSecure OpenClaw on a Mac mini: Remote Access First, Agent Setup Second
A security-first guide for running OpenClaw on a Mac mini: protect the Mac access path first, keep the gateway local, then install the agent stack.
Read guideWhy 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.
Read guideVNC 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.
Read guideWhy the VNC Address Stays localhost
When VNC is protected behind SSH, localhost is not a placeholder. It is the address that keeps the screen service behind the tunnel.
Read guideTailscale and HearthGate: Network Layer vs Mac Gateway Layer
Tailscale is excellent at making private devices reachable. HearthGate solves the next Mac-specific question: what happens on the host after it is reached?
Read guideSSH Hardening for Mac Remote Access
A Mac remote-access gateway should treat SSH as a carefully managed entry point: keys, ports, bindings, login policy, timeouts, and cleanup all matter.
Read guidePost-Quantum-Ready SSH: ML-KEM Hybrid Explained
Post-quantum-ready SSH is not a magic shield. It is a practical way to use hybrid key exchange when the installed SSH stack supports it.
Read guidePlatform and viewer paths
Secure Mac access is rarely one client. The useful pattern is a consistent Mac-side gateway with familiar viewers on the device in front of you.
Secure access glossary
Definitions, keywords, and phrases for VNC over SSH, localhost, authorized_keys, Per-Key Limits, ML-KEM, and more.
Per-Key Limits
Limit Mac SSH keys by expiration date, schedule, concurrent sessions, lifetime use, and session duration.
Windows to Mac with TightVNC
Use a local VNC target while the Mac-side screen path stays behind SSH.
MobaXterm to Mac Screen Sharing
Keep the SSH gateway and VNC target separated in a Windows workflow.
Screens on iOS
Connect from iPad or iPhone with the SSH tunnel pointed at HearthGate.
Remmina on FreeBSD
Use Remmina with a HearthGate tunnel and a local VNC endpoint.