How to Set Up SSH Key Authentication on Mac (and Why You Should Never Use Passwords)

How to Set Up SSH Key Authentication on Mac (and Why You Should Never Use Passwords)

If you've been logging into servers with a username and password, you're one leaked credential away from losing that server. SSH key authentication isn't just "more secure" — it changes the entire threat model. Once you understand how it works, you'll never go back.

This guide walks you through the full setup on a Mac, step by step, with the reasoning behind every decision.

First, understand what you're actually building

SSH key authentication works like a padlock you put on a door. You keep the key (private key) on your laptop. You put the matching padlock (public key) on the server. When you connect, SSH proves you hold the key — without ever sending it over the network. Even if someone intercepts every byte of traffic, they learn nothing useful.

A password, by contrast, travels to the server on every login. One phishing attempt, one leaked database, one shoulder-surf — and it's gone.

Step 1 — Generate a dedicated key pair for this server

Most people generate one SSH key and reuse it everywhere. Don't. Use a separate key per server or per purpose. That way, if one key is ever compromised, you revoke it in one place without touching anything else.

ssh-keygen -t ed25519 -C "you@server-name" -f ~/.ssh/server_name

Breaking this down:

• -t ed25519 — the algorithm. Ed25519 is the modern standard: shorter keys, faster, and cryptographically stronger than the older RSA 2048. Always use this unless the server is ancient.
• -C "you@server-name" — a comment embedded in the public key. It doesn't affect security, but six months from now when you're looking at a server's authorized_keys file and see five entries, you'll be grateful you labeled them.
• -f ~/.ssh/server_name — the filename. Be precise here. A typo (server-name vs server_name) means the next command will fail with "No such file or directory." Run ls ~/.ssh to confirm the file was created before moving on.

When prompted for a passphrase, set one. Your private key file is essentially a master password in a file — if someone copies it off your laptop, the passphrase is the only thing stopping them from using it. macOS Keychain will remember the passphrase for you, so you only type it once per reboot.

Step 2 — Copy the public key to the server

This is the step that "puts the padlock on the door." You're appending your public key to ~/.ssh/authorized_keys on the server — a file SSH checks on every connection attempt.

ssh-copy-id -i ~/.ssh/server_name.pub user@SERVER_IP

Notice the .pub extension — you're sending the public key, not the private one. Your private key (~/.ssh/server_name without .pub) never leaves your machine. Ever. If anyone asks you to send them your private key, that's a red flag.

This command will ask for your password one last time — it needs it to log in and place the key. After this step, you'll never need the password again.

Step 3 — Create a named alias in your SSH config

You could type ssh -i ~/.ssh/server_name [email protected] every time. But you won't — you'll forget the flags, use the wrong key, and end up debugging authentication errors at 2am. Instead, write it down once in ~/.ssh/config:

Host server-alias
    HostName SERVER_IP
    User your_username
    IdentityFile ~/.ssh/server_name
    IdentitiesOnly yes

The line most tutorials skip explaining: IdentitiesOnly yes. Without it, SSH will try every key in your ~/.ssh/ folder, one by one, before trying the right one. On hardened servers that lock you out after a few failed attempts, this can get you banned by your own SSH client before the correct key is even tried. IdentitiesOnly yes says: use only the key I specified, nothing else.

Now test it:

ssh server-alias

If you get a shell prompt, the key is working. Do not proceed to Step 4 until this works.

Step 4 — Lock the door: disable password authentication on the server

Key login working is not enough. As long as password authentication is enabled, your server is still accepting passwords — and still vulnerable to brute-force attacks. This step removes that attack surface entirely.

Before you make any changes: open a second terminal and verify you can still ssh server-alias in. If you misconfigure sshd_config and lock yourself out, your existing session stays alive. That's your lifeline to fix it. Never edit SSH config with only one active session.

On the server, edit /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

Each line matters:

• PasswordAuthentication no — the main goal. No more passwords accepted.
• PermitRootLogin no — attackers always try root first. Remove the target entirely.
• ChallengeResponseAuthentication no and UsePAM no — these close side doors that can sometimes re-enable password prompts even when PasswordAuthentication is off. Set all three.

Apply the changes:

sudo systemctl restart sshd

Then, from a new terminal on your laptop, run ssh server-alias. If it connects without asking for a password, you're done. If it asks for a password, something in the config didn't apply — go back and check for typos, then restart sshd again.

Step 5 — Add a final layer of protection against bots

Even with passwords disabled, bots will hammer port 22 all day long. It wastes resources and pollutes your logs. Two quick fixes:

# Auto-ban IPs that repeatedly fail authentication
sudo apt install fail2ban -y
sudo systemctl enable fail2ban --now

And optionally, change the SSH port in /etc/ssh/sshd_config:

Port 2222

Changing the port doesn't stop a determined attacker — a port scan finds it in seconds. But it eliminates 99% of automated bot traffic, which never scans beyond port 22. Update your ~/.ssh/config to match:

Host server-alias
    HostName SERVER_IP
    User your_username
    IdentityFile ~/.ssh/server_name
    IdentitiesOnly yes
    Port 2222

What you've actually built

You now have a server that:

• Only accepts cryptographic proof of identity — no passwords, no brute-force surface
• Refuses root login entirely
• Auto-bans IPs that probe it repeatedly
• Is reachable from your laptop with a single memorable alias

The mental model to take away: your private key is a physical key you never duplicate or hand to anyone. Your public key is a lock you can put on as many doors as you want. The config file is your keychain — it tells SSH which key to use for which door, without you having to think about it every time.

Do this for every server you ever touch. It takes five minutes and it will save you from the kind of incident that ends careers.