1. Why Harden Your Cloud Mac?

A dedicated Mac server is reachable from the public internet the moment it is provisioned. Username and password access is convenient, but passwords can be brute-forced and open management ports invite automated attacks. The good news: a few well-understood steps — SSH keys, a tight firewall, and a private VPN — remove the vast majority of that risk. Every MyRemoteMac server already supports key-based authentication, a managed firewall, and a WireGuard VPN out of the box.

Defense in depth: No single control is enough. Combining key-based SSH, a default-deny firewall, and VPN-only management forces an attacker to defeat several independent layers.

2. Prerequisites

Before you start, make sure you have:

A Mac server from MyRemoteMac with SSH access
An SSH client on your local machine (built into macOS, Linux, and modern Windows)
Your server's IP address and default credentials
Basic comfort with the terminal

3. Step 1: SSH Key Authentication

Key-based authentication replaces a guessable password with a cryptographic key pair. You keep the private key; the server stores only your public key, so there is no password for an attacker to brute-force.

Generate a key pair

On your local machine, generate a modern Ed25519 key (skip this if you already have one):

# Generate a modern Ed25519 key pair on your LOCAL machine
ssh-keygen -t ed25519 -C "you@example.com"

# Print the PUBLIC key (this is what you give the server)
cat ~/.ssh/id_ed25519.pub
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... you@example.com

Add your public key, then disable passwords

In your MyRemoteMac dashboard, open Security and paste your public key — or select it when provisioning a new server. Once you have confirmed that key login works, disable password authentication:

# On the SERVER, disable password login once your key works
sudo sed -i '' 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i '' 's/^#*ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config

# Restart the SSH daemon to apply
sudo launchctl kickstart -k system/com.openssh.sshd

4. Step 2: Lock Down the Firewall

Expose only what you need. MyRemoteMac includes a managed network firewall, and you should also enable the on-host macOS application firewall for a second layer.

Enable the macOS application firewall

# Enable the built-in macOS application firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

# Enable stealth mode (don't respond to pings / closed-port probes)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

# Verify
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Restrict inbound ports

In the MyRemoteMac managed firewall (dashboard or API), allow inbound traffic only on the ports you actually use — typically SSH (22) restricted to your IP or VPN — and deny everything else by default.

5. Step 3: Private VPN (WireGuard)

The strongest posture is to never expose management ports publicly at all. Every MyRemoteMac server includes a private WireGuard/IPSec tunnel: connect to it first, then reach SSH and VNC over the private network.

# Bring up the WireGuard tunnel from your local machine
wg-quick up wg0

# Now reach your Mac over the PRIVATE address, not its public IP
ssh you@10.0.0.2

Once the tunnel is up, restrict SSH and VNC in your firewall to the VPN subnet only. Your Mac then becomes invisible to public port scanners.

6. Step 4: Ongoing Hardening

Security is continuous, not a one-time task. Apply these durable measures:

Keep macOS updated — install security updates promptly to close known vulnerabilities.
Enable FileVault — full-disk encryption protects your data at rest.
Use a non-root admin user — work through sudo rather than logging in as root.
Rotate and scope SSH keys — remove keys you no longer use from Security.
Monitor authentication logs — watch for failed logins and unexpected sessions.
Back up regularly — pair hardening with off-site backups for ransomware resilience.

7. Troubleshooting

Locked out after disabling password login

Reconnect with VNC / Screen Sharing from the dashboard, temporarily re-enable password login, and verify your public key is in ~/.ssh/authorized_keys with the correct permissions (700 on ~/.ssh, 600 on the file).

SSH still asks for a password

Check permissions: ~/.ssh must be 700 and authorized_keys 600. Confirm sshd_config has PubkeyAuthentication set to yes, and that you are offering the matching private key with ssh -i.

Locked out by a firewall rule

Always keep one VNC / Screen Sharing session open while changing firewall rules. If you lose SSH, use VNC to revert the rule, then re-apply it scoped to your VPN subnet.

8. Security Checklist

Run through this checklist after provisioning any new Mac server:

SSH key authentication enabled
Password login disabled (or restricted to the VPN)
macOS application firewall enabled with stealth mode
Inbound ports default-deny; SSH and VNC scoped to the VPN
FileVault enabled and macOS up to date
Unused SSH keys removed and off-site backups configured

In short: key-based SSH, password login disabled, a default-deny firewall, management over VPN, FileVault on, and keys rotated regularly. Do this once and your cloud Mac is dramatically harder to attack.

How to Secure Your Cloud Mac: SSH Keys, Firewall & VPN

Table of Contents