SSH Local Forward or Full VPN for One Mac Screen?

You need to see one Mac's screen from your own machine, the Mac sits behind a host you can already SSH to, and the question is whether that deserves a VPN. Usually it does not. A single local forward carries one TCP port through the SSH session you already have, and for one screen on one host that is a smaller, more auditable arrangement than routing an entire network.

Three conditions decide it, and any one of them can push you toward the managed VPN instead.

Three conditions decide it

The first is scope: one service on one host, or several hosts and several ports. The second is whether every hop between the bastion and the target is already trusted, because SSH protects only the segment it terminates. The third is who must support the arrangement after you build it, since a hand-rolled tunnel tends to outlive the person who understood it. Name that person before you start, and write the command in a place they can find. An undocumented forward is a future incident with a delayed start date.

If the answers are "one", "yes", and "me, for now", the forward is the right tool. If any answer changes, a supported remote-access design is cheaper over a year than the incident review that follows an undocumented tunnel.

Forward one port, not the network

A local forward opens a listener on your machine and relays each connection through the SSH server to a destination that server can reach. For a Mac whose screen-sharing service listens on TCP 5900, and a bastion that can resolve mac.corp.example, the command is short and deliberately narrow. Every option in it exists to keep the arrangement small: no shell, no wildcard listener, no daemon. Read it as a scope statement rather than as a recipe.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Binding the listener to 127.0.0.1 keeps it off every other interface. That is not a formality: a forward bound to all interfaces turns your laptop into an open relay into the corporate network for anyone on the same cafe Wi-Fi. If the port is already in use, pick another high port and update the viewer; do not stop an unrelated service to make the example fit.

The account on the bastion also needs permission to forward to that destination. Some hardened SSH configurations disable port forwarding entirely, and some restrict it with a permit-listen or permit-open directive. Read the server policy before assuming a refused channel means the password was wrong.

What SSH encrypts, and where it stops

The SSH session protects traffic from your Mac to the bastion, and the forward carries the VNC protocol inside that session without understanding it. Once the connection leaves the bastion toward the target, it is no longer inside your SSH session. Whatever protection exists on that last hop belongs to the target protocol and to the private network's own controls.

That is why a plain VNC final hop should not be described as end-to-end encrypted merely because the first hop used SSH. Describe the segments honestly: strong from client to bastion, and whatever the target supports after that. If the requirement is that the whole path be encrypted by one mechanism, the forward does not meet it.

Authentication at the target is separate again. The SSH account does not grant a macOS login, and the screen-sharing service still asks for its own credentials and still applies its own access list. A local listener that accepts a connection proves nothing about whether the remote service will admit the session.

When the full VPN is the right call

Choose the VPN when the task needs more than one port: Apple Remote Desktop's management and reporting functions use additional TCP and UDP traffic that a single TCP forward will not carry. A forward is not a partial implementation of the whole product; it is a different, smaller tool.

Choose it when several administrators connect from changing locations, because a managed profile distributes routes, credentials, and policy without each person inventing a command line. Choose it when the audit trail has to show who connected to what, since a per-user SSH session and a shared local forward leave very different records.

Choose it, finally, when the target network should not be reachable from a laptop at all without the organization's own gate. A personal forward bypasses that gate by design, which is exactly why it belongs in a change record rather than in a shell history.

Make the forward fail loudly

Use ExitOnForwardFailure=yes so a failed bind stops the session instead of leaving a shell that looks connected and forwards nothing. Keep host-key verification on, and prefer a key or agent over a password. Then test the exact URL the viewer will use, because a working SSH session and a working screen connection are two different results.

For the native client on macOS, the viewer is reached through a local URL: open "vnc://127.0.0.1:15900". If the window opens and the remote host rejects authentication, the tunnel is fine and the problem is on the target. If the window never opens, the listener or the port is the problem.

Stop the session when you are done, and write down the port, the bastion, the target, and the account policy. A forward that nobody documented is indistinguishable from a backdoor six months later, which is the strongest argument for keeping it small, named, and temporary.