Enabling and Hardening Remote Login (SSH) on macOS

macOS ships with a fully capable OpenSSH server built in, exposed through the “Remote Login” setting rather than requiring any separate installation — but the default configuration once enabled is intentionally permissive, and hardening it beyond the default is worth doing for any Mac you’re actually going to expose to remote SSH access regularly.

System Settings > General > Sharing > Remote Login

or, from the command line:

sudo systemsetup -setremotelogin on

Once enabled, the Mac accepts SSH connections on port 22 for any user account with login access, authenticated with that account’s regular password by default — which is the first thing worth changing.

Restricting which users can actually connect

The Sharing preference pane lets you restrict Remote Login access to specific user accounts (or groups) rather than leaving it open to every account on the machine, which is worth doing explicitly even on a single-user Mac, since it documents intent clearly rather than relying on there simply not being other accounts to worry about:

System Settings > General > Sharing > Remote Login > select specific users

Switching to key-based authentication

Password authentication over SSH is vulnerable to brute-force attempts against any exposed instance, and switching to public-key authentication removes that entire attack surface. Generate a key pair on the client machine you’ll be connecting from (not the Mac being configured):

ssh-keygen -t ed25519 -C "your-client-identifier"

Copy the public key to the Mac being configured for remote access:

ssh-copy-id username@mac-hostname

Disabling password authentication entirely

Once key-based login is confirmed working, disabling password authentication entirely closes off brute-force attempts against the SSH service completely:

# /etc/ssh/sshd_config.d/hardening.conf
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

macOS’s OpenSSH configuration supports drop-in files under /etc/ssh/sshd_config.d/, which is the cleaner way to apply overrides without editing the main sshd_config file directly — keeping your hardening changes isolated and easy to review or revert independently of Apple’s own shipped default configuration.

Restart the SSH service for changes to take effect:

sudo launchctl kickstart -k system/com.openssh.sshd

Changing the default port, if exposing this beyond a local network

If Remote Login needs to be reachable from outside your local network (via router port forwarding, for instance), changing the listening port away from the default 22 meaningfully reduces the volume of automated, opportunistic scanning traffic that constantly probes the default SSH port across the entire internet:

# /etc/ssh/sshd_config.d/hardening.conf
Port 2222

This isn’t a security boundary by itself (anyone doing a targeted, deliberate port scan will still find it), but it does substantially cut down on noise from automated, non-targeted scanning attempts, which is a meaningful practical benefit for reducing log noise and unnecessary connection attempts even if it’s not real security through obscurity.

Verifying the hardened configuration is actually in effect

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|port'

sshd -T dumps the actual, fully-resolved effective configuration (after all drop-in files and defaults are combined), which is the reliable way to confirm your hardening changes actually took effect as intended, rather than assuming a config file’s presence alone guarantees its settings are active.

Why this is worth doing even for occasional, infrequent remote access

Even a Mac that’s only remotely accessed occasionally benefits from being hardened by default rather than only when actively expecting a connection — Remote Login, once enabled, remains listening continuously until explicitly disabled, and a machine’s actual usage pattern (frequent versus rare remote access) doesn’t change how continuously exposed the listening SSH service itself actually is to anything that can reach it on the network.