Remote Login on a Mac, set up properly

Remote Login is the Sharing switch that starts macOS’s SSH server. Turn it on and the Mac listens on TCP port 22 for SSH, and with it SFTP and scp, because they ride the same service — Apple’s port list files all three under 22. Anyone who can reach that port with a Mac account or a key you have authorized gets a shell as that user. The server is OpenSSH, the same one every Linux box runs, so everything you know about ssh applies.

Two macOS-specific details. The switch has an “Allow full disk access for remote users” option, because macOS protects folders like Desktop and Documents from processes that have not been granted access, and an SSH session is one; leave it off until a job needs it. And since macOS Tahoe 26, a FileVault-encrypted Mac can be unlocked over ssh after a restart if Remote Login is on and the network is up — the first time a headless Mac with FileVault has been manageable from a distance.

From another Mac or a Linux machine, it is the line the Sharing pane showed you: ssh you@your-mac.local. The .local name is resolved by Bonjour and works only on the same network; elsewhere use the address or a name you control. The first connection shows the Mac’s host key fingerprint and asks you to accept it; that is how your client recognises the Mac from then on.

Windows 10 and 11 carry Microsoft’s OpenSSH client as an optional feature, usually already present — ssh works from PowerShell, and Microsoft’s OpenSSH guide covers adding it. From a phone, any SSH app reaches Remote Login with the same account or key; SSH from an iPhone covers the apps, and the honest summary is small type and a session that ends when the app is backgrounded.

Remote Login makes the Mac listen; it does nothing to make it reachable. On your own Wi-Fi the two coincide; from anywhere else your router’s NAT stands in the way, and you have three honest options. Forward TCP 22 from the router to the Mac, which puts sshd on the public internet: fine with keys only and named users, reckless with passwords, dependent on dynamic DNS to find your changing home address, and impossible behind carrier-grade NAT, where you have no public address to forward from.

Or put the Mac on a private network: Tailscale and its peers give the Mac and your other devices addresses that reach each other across NAT without forwarding, and Remote Login answers on the tailnet address as it does on the LAN, for the price of a client on every device. Or use something that never needs the Mac to listen at all — where this page turns, below.

Everything above is the right way to run SSH on a Mac, and at home with keys and a named user it is a good way to live. Its two limits are structural. The Mac must listen, so reaching it from outside means a forward or a VPN and a client on every device. And a session belongs to the connection: close the laptop, lose the train’s Wi-Fi, background the app on the phone, and the shell — with the build or the agent in it — is gone unless you remembered tmux.

spawnd inverts both. One daemon runs on the Mac and dials out; nothing listens on the host, no port is forwarded, no VPN is needed. A worker process on the Mac owns each session’s PTY, so a session survives the closed tab, the dropped connection, the laptop lid, and a daemon restart, scrollback intact. Any browser is the console, and on a phone it installs to the home screen as a web app — no client app, no keys on the device; a new device is approved once against a short code, and revoking it is one click every host honors. Your browser talks to each daemon peer-to-peer, end-to-end encrypted, and the server that introduces them never sees session content. Remote Login can stay on beside it for scp and the tools that expect a port, or go off. If you stay with SSH, the tmux cheatsheet is the persistence half of that route; remote access to your Mac puts every method, this one included, side by side.