Add Two-Factor Auth to Remote Mac Login Guide

Published November 11, 2026 • Figment editorial team

The reliable way to put two-factor authentication in front of a remote Mac is to gate the network path with an identity provider that already enforces MFA, then let macOS Remote Login handle only the authenticated final hop. That keeps a documented, provider-supported MFA flow in control of who can reach TCP/22 on the Mac, avoids weakening the operating system by editing /etc/pam.d/sshd, and leaves recovery in the hands of the account owner through the same console that was used to set the Mac up. This guide shows the architecture, the small set of commands you actually need, and a buyer checklist for the questions to settle in the quote before you rent.

A note on scope: the recipe below is network-access MFA, not macOS local-password MFA. Figment's $29/month virtual Intel macOS plan is reached through an owner-authenticated browser console rather than a public SSH endpoint, so the SSH-tunnel pattern here applies to a physical rental where inbound SSH is agreed in writing. Account-level authentication to the Figment console is a separate policy confirmed with the support team; this article does not claim a product TOTP or WebAuthn feature on the $29 plan. For a plan that can host Apple Remote Login behind your own identity provider, request the i3 Mac from $49/month or an M-series Mac from $95/month at /mac-hosting/start and confirm the exact chip, RAM, disk, inbound SSH, and admin boundaries in the quote.

Why Network-Level MFA Beats Editing macOS PAM

Guides that paste a Linux PAM recipe onto macOS tend to suggest adding pam_google_authenticator.so to /etc/pam.d/sshd with nullok enabled during rollout. That pattern has three problems on a rented Mac. First, nullok means any account without an enrolled TOTP file bypasses the second factor entirely, which is not MFA. Second, the library path varies by Homebrew prefix and by macOS version, a single wrong path in an auth required line can lock every user out of SSH at once, and recovery depends on hardware-level console access that is not promised on every plan. Third, Apple's Remote Login documentation describes the standard password or key prompt and does not document a supported second-factor hook, so a PAM edit is an unsupported local modification you now own forever across macOS updates.

Pushing MFA up the stack fixes all three. A tailnet or Zero Trust tunnel refuses to forward traffic to port 22 until the user has completed MFA at your identity provider, the Mac's sshd stays stock, and recovery is "remove the device from the tailnet or the Access application" rather than "comment out a line in a PAM file you cannot reach." The admin who owns the Mac must also close the direct public alternate path to port 22 at the host firewall and test, from a device outside the tunnel, that the block is in effect.

Option A: Identity-Provider MFA With Tailscale or Cloudflare Access

Both options are documented by the vendor and are not bundled by Figment; you bring your own account and configure MFA at your identity provider.

Tailscale delegates authentication to the identity provider you already use. Its enable two-factor and multifactor authentication guide states plainly that "Tailscale relies on your existing identity provider to authenticate users" and "any authentication settings from your identity provider are automatically used by Tailscale, including MFA." The workflow is: enable MFA in Google Workspace, Microsoft Entra ID, Okta, OneLogin, or your SAML/OIDC provider; install the Tailscale client on the rented Mac and on each operator's laptop; set an ACL that allows SSH only from a tagged operators group to a tagged Mac host. The public internet never sees port 22.

Cloudflare Access covers the same job for teams already on Cloudflare One. Its MFA requirements policy documentation describes both identity-provider-based MFA and independent MFA, and notes that "if the user fails to present the required MFA method, Cloudflare Access rejects the user, even if they successfully log in to the identity provider with an alternative method." For an SSH target you create a self-hosted Access application in front of the Mac, require an authentication method such as a FIDO2 or PIV key, and connect through cloudflared access ssh on the client side.

Pick one. Running both at once adds moving parts without improving the authentication story.

On the Mac itself, keep the macOS side boring. Apple documents Remote Login at support.apple.com/guide/mac-help/mchlp1066: System Settings, General, Sharing, turn on Remote Login, and restrict it to the specific user accounts your team will use. Add SSH public-key authentication for each account so the password path is not the one in use day to day, and keep one per-person account per operator rather than a shared login.

Once Tailscale or Cloudflare Access is in place and the admin has confirmed the public path to port 22 is closed, a VNC or Screen Sharing session uses an SSH tunnel through the same authenticated hop rather than exposing RFB to the internet:

# After your MFA gate has authorised you, forward local 5901 to the Mac's
# Screen Sharing port over the already-authenticated SSH connection.
ssh -L 5901:localhost:5900 -N user@mac-inside-tunnel
# Point your VNC client at 127.0.0.1:5901

No change to /etc/pam.d/sshd, no nullok, no local PAM path to maintain. If you later decide you need a second factor at the Mac itself, do it with a vendor-supported mechanism (for example a Jamf-managed policy on an enterprise plan) rather than a hand-edited PAM stack.

Buyer Checklist and Figment Plan Choice

Use this checklist in the quote conversation and in your own runbook. It is the unique artifact of this article; keep it in the repo next to the tunnel config.

Where is MFA enforced? Identity provider in front of the tunnel, not on the Mac's local login.
What is the session expiry? Set it at the identity provider and at the tunnel ACL; shorter wins.
How do you revoke a leaver? Remove them from the identity-provider group and from the tailnet or Access application; test the removal the same day.
What is the recovery path if the gate misbehaves? An owner-controlled console into the Mac that does not depend on the broken tunnel. Confirm this per plan in the quote.
Is there an alternate ingress to the Mac, and has the admin tested that it is closed from outside the tunnel?
Are there per-user accounts on the Mac, or one shared login? Per user, with individual SSH keys and individual identity-provider logins.
Who owns admin on the rented Mac, and what does that owner commit to in writing in the quote?

Figment plan choice maps to the work, not to the MFA method. The $29/month virtual Intel macOS plan is good for compile and signing work with supported Intel Xcode 26-or-earlier toolchains, reached through its browser console rather than inbound SSH. The i3 Mac from $49/month fits Intel work that needs more sustained CPU or an agreed SSH endpoint behind your identity-provider gate. The M-series Mac from $95/month covers arm64 execution, Xcode 27, and visionOS targets where chip, RAM, and disk are confirmed in the quote. Physical Intel and M-series plans are request-based rather than instant; start the quote at /mac-hosting/start and tell the team which MFA gate you plan to run, which operator accounts need keys, and which inbound ports should be closed at the edge.

Related guides: