Guides / Remote access security

Secure remote Mac access: SSH and Screen Sharing with least privilege

Updated 2026-10-22 · Based on Apple and OpenBSD documentation

Start by deciding what the task requires. SSH is for command-line access and file transfer; Screen Sharing is for interactive GUI control. They grant different capabilities, so authorize them separately. A practical baseline is to enable only the service in use, allow only named accounts, and remove temporary access when the work is done.

Know what each service can do

Remote Login (SSH): Apple describes it as a way to log in over SSH, with SFTP available for file transfer. It supports terminal work and automation, but does not provide a graphical desktop.
Screen Sharing: It lets a remote user view and control the Mac desktop. Apple notes that a connected user can open, move or close files and apps, and restart the Mac. Treat it as a broad control permission, not a view-only window.
VNC clients: macOS has a separate option for VNC viewers to control the screen with a password. Enable it only when a VNC-compatible client is required, and protect it as an additional remote entry point.

Apple says Screen Sharing and Remote Management cannot be enabled at the same time. If you only need a terminal, do not turn on a GUI service for convenience. If you need the desktop, do not assume every remote user also needs administrative control.

Limit who can connect

In macOS System Settings, open General → Sharing and enable only the remote services required for the task.
Review the allowed users for Remote Login and Screen Sharing separately. Where macOS offers “Only these users,” name the accounts that need access instead of treating every local account as a remote user.
Use a separate standard account for routine work where practical. Use administrator privileges only for tasks that need them; avoid making an admin account your everyday remote login.
Apple lists “Allow full disk access for remote users” as a separate setting. Ordinary SSH or desktop access should not automatically receive it. Assess that permission only for a task that requires it, then review it again when the task ends.

Protect SSH credentials and verify the host

When the server supports it, prefer public-key authentication. Use separate keys for different users or environments and protect each private key. Never put a private key in a code repository, shared document or chat. When someone leaves a project, a device is lost or a key may have been exposed, remove the corresponding public key from the Mac and rotate related credentials through your team’s process.

Verify the SSH host key when connecting: obtain the server fingerprint through a trusted console or administrator channel, then compare it with the fingerprint shown by your client. Do not accept a new key when you cannot confirm the host’s identity. OpenSSH’s StrictHostKeyChecking option can make the client reject unknown or changed host keys; with yes, it does not automatically accept a host-key change.

If a familiar host suddenly reports a changed key, stop and confirm through a trusted channel whether there was a planned reinstall or key rotation. Do not remove the old record or disable checking just to clear the warning; the change could also mean you reached a different host.

Keep GUI access within its intended scope

Screen Sharing can control the desktop, so grant it only to people who need GUI access and use a unique, strong credential. If you enable the VNC option, choose a dedicated VNC password rather than reusing an Apple Account or another important password. Turn off VNC access when it is no longer needed.

Before connecting from an external network, check the access method documented by the host or network administrator. When available, prefer a VPN, private network or explicit source-address restriction. Do not expose SSH or VNC to the entire internet without access controls. The available network restrictions depend on your environment, so follow its actual administration documentation.

Use a repeatable access review

Remove former team members, temporary collaborators and unused accounts from the remote-user lists.
Check whether SSH, Screen Sharing and VNC access are still needed; turn off entry points that are not in use.
Remove SSH public keys that are no longer valid or owned by an active operator, and make sure private keys were not copied to shared storage.
After a reinstall or host-key rotation, verify the new fingerprint through a trusted channel before changing the client’s trust record.
When a task requiring full-disk access or another elevated permission ends, restore the least-privilege settings needed for routine work.

Sources

This is a general remote-access security guide, not a security assessment of any cloud Mac provider. macOS versions, network policies and hosted environments differ; check the official administration documentation for your device and service.