SSH Hardening
How HearthGate stacks global defaults, per-key exceptions, and server-level SSH feature lockdown so each key gets only the access it should have.
Global and per-key restrictions, without pretending they are the same thing
HearthGate hardens SSH in layers. The global key default decides what new keys become, the per-key switch lets you grant one named exception when someone really needs more than screen access, and the server-level hardening setting defines what nobody can do through sshd.
That split matters because VNC over SSH still needs local port forwarding. A VNC-only key can be limited to the screen tunnel, but the broad SSH feature surface is safer when the Mac's SSH daemon also blocks the risky paths globally.
Default policy
New keys can start narrow: VNC tunnel only, no shell, no file transfer, no broad SSH behavior.
Named exception
A trusted admin key can be created with full SSH when terminal, SFTP, SCP, rsync, or Terminal Actions are part of the job.
Server floor
Agent forwarding, reverse tunnels, X11 forwarding, Unix socket forwarding, and gateway ports are blocked for every key.
Three locks, one door
These settings stack instead of overlapping. OpenSSH applies the most restrictive effective rule, so each layer closes a different class of mistake.
| Layer | What it is | Where it is enforced | Who it affects | Real-world result |
|---|---|---|---|---|
| Restrict new keys to VNC tunnel only | A global default for newly generated keys. | The generated authorized_keys entry is narrowed to the screen tunnel path. | New HearthGate keys. | A family member, contractor, or temporary helper can view the Mac through the protected tunnel, but a stolen key cannot become a shell or file-transfer credential. |
| Allow full SSH access for this key | A deliberate per-key exception. | The selected key is created without the VNC-only restriction, then remains visibly separate from routine screen-only keys. | One named key. | Your own admin key can use terminal, SFTP, SCP, rsync, VS Code Remote-SSH, or Terminal Actions while other people keep VNC-only access. |
| Lock down SSH features | A server-level floor enforced by sshd. | Risky SSH capabilities are disabled at the daemon layer, even for full-access keys or keys added outside HearthGate. | Every key on the Mac. | A manually pasted key or over-broad full-access key still cannot open reverse tunnels, agent forwarding, X11 forwarding, Unix socket forwarding, or gateway ports. |
Why the server layer exists: a VNC tunnel needs local forwarding to work, so the key layer should stay focused on the screen path. The server layer is where HearthGate blocks reverse tunnels, SSH agent forwarding, X11 forwarding, Unix socket forwarding, layer-2 tunneling, and external gateway ports for everyone.
Remote help without handing over the Mac
Create a VNC-only key for a friend, parent, contractor, or client. They can reach the screen through the SSH tunnel, but the same key cannot quietly become a shell, SCP, or SFTP credential.
Admin access that is explicit
Keep your own key full-access when you need terminal work, Terminal Actions, rsync, or file transfer. The exception is visible at the key level instead of being hidden inside a general server setting.
A floor under every key
Server-level lockdown covers keys that did not come from HearthGate, including emergency keys, imported keys, or material added by hand. This closes SSH escape hatches that per-key screen restrictions are not meant to solve.
Recommended posture: leave global SSH feature lockdown enabled, keep new keys VNC-only by default, and create full-access keys only for people or workflows that genuinely need shell, file transfer, Terminal Actions, or development tunnels.