SSH Key Generator on Mac: A Complete Terminal Workflow

Why SSH keys still matter on macOS

Every Mac ships with the same OpenSSH toolchain that powers a large share of the internet's server infrastructure. That means you do not need to install anything to create a modern, hardware-grade authentication setup. You open Terminal, run one command, and you have a cryptographic identity that can log you into a VPS, push commits to a Git host, deploy to a cloud provider, or tunnel into a database behind a firewall.

The appeal is simple: passwords can be guessed, phished, reused, or leaked from a database breach. A key pair cannot be guessed in any practical sense. The private half never leaves your machine, and the public half is safe to paste anywhere. When a server challenges you, your Mac proves possession of the private key without ever transmitting it. An attacker who compromises the server's stored public keys gains nothing useful.

That asymmetry is why most hosting providers, code forges, and cloud platforms now push key-based access as the default and often disable password logins entirely. If you have ever been locked out of a fresh server because password authentication was switched off, the fix was almost always to upload a public key first.

Mac users get a few extra conveniences on top of the standard stack. The system Keychain can remember passphrases, the ssh-agent launches automatically in most shells, and GUI clients integrate with the same ~/.ssh directory that Terminal uses. So whether you prefer typing commands or clicking through a polished app, everything stays in sync.

This guide walks through the full lifecycle: generating keys, choosing the right algorithm, protecting the private key with a passphrase, wiring up config files, and fixing the errors that trip people up most often. It also covers how to turn the whole process into a repeatable walkthrough you can hand to teammates.

How key-based authentication actually works

Before running commands, it helps to understand the handshake, because almost every confusing error message maps back to one of these steps.

The two halves of a key pair

When you generate a key pair, the tool produces two mathematically linked files:

• The private key (for example id_ed25519) stays on your Mac. It is the secret. Anyone who copies it can impersonate you.
• The public key (id_ed25519.pub) is a short text string you can share freely. It gets appended to a file called authorized_keys on each server you want to reach.

During login the server sends a random challenge. Your SSH client signs it with the private key, and the server verifies the signature using the public key it already has. No secret crosses the wire.

Where the host side keeps its list

On a typical Linux server, your public key lives in ~/.ssh/authorized_keys inside your user account. One line per key, one key per line. If your key is not in that file, or the file has permissions the SSH daemon considers unsafe, authentication fails even though your local setup is perfect.

Why the first connection asks a question

The very first time you connect, your client shows a fingerprint prompt and asks whether to trust the host. Saying yes writes an entry to ~/.ssh/known_hosts. From then on, a changed host key triggers a loud warning, because it can indicate a man-in-the-middle attempt or a rebuilt server.

What the agent does

Running an SSH agent means you unlock your private key once per session instead of typing the passphrase on every connection. On macOS the agent and the Keychain can be linked, so the passphrase survives reboots and logins without you thinking about it.

Once these four pieces make sense — private file, public file, server-side list, agent cache — troubleshooting becomes a matter of asking which one is misconfigured.

Generating your first key pair in Terminal

Open Terminal with Spotlight (Command + Space, then type Terminal) or find it under Applications > Utilities. Then run:

ssh-keygen -t ed25519 -C "you@example.com"

The -t flag selects the algorithm, and -C attaches a comment that helps you identify the key later. The comment is not secret; using your email or a device name is a common convention because hosting dashboards display it in lists of authorized keys.

Answering the prompts

The tool asks three things:

1. File location. Press Return to accept ~/.ssh/id_ed25519, or type a custom path such as ~/.ssh/id_ed25519_work_laptop. Custom names are the single best habit for keeping separate identities for work, personal projects, and client systems.
2. Passphrase. Enter a strong one, or press Return twice for none. Empty passphrases are convenient for throwaway containers and genuinely risky for laptops that travel.
3. Confirmation. Type the passphrase again.

You will see output like a random art block and a confirmation that the key was saved. Two files now exist:

ls -la ~/.ssh

Reading the output safely

To view the public key, use:

cat ~/.ssh/id_ed25519.pub

That single line is what you paste into a Git host, a cloud console, or a server's authorized_keys. Never paste the file without the .pub extension. A quick sanity check: the private key starts with -----BEGIN OPENSSH PRIVATE KEY----- and should never leave your machine, not even to a password manager you do not fully control.

Copying the key to a server

If the server still accepts password login and you have ssh-copy-id available:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.com

Otherwise, paste the public key line manually into ~/.ssh/authorized_keys on the remote host using whatever access you currently have.

Recording the process for your team

A written runbook plus a short screen recording covers nearly every onboarding case. When you capture the walkthrough, keep the Terminal font large, narrate why each flag exists rather than only what to type, and hide or blur any fingerprint or key material that appears on screen. If you produce the recording with an AI-assisted video tool, favor a consistent visual style and add captions for the exact commands, because viewers will pause the video to copy them.

Choosing the right algorithm, size, and file names

Not all key types are equal, and the choice you make now determines how much friction you feel later.

Ed25519 versus RSA versus ECDSA

• Ed25519 is the modern default. Keys are short, signing is fast, and the algorithm avoids several classes of implementation pitfalls. It works on any reasonably current server or Git host.
• RSA remains the compatibility fallback. Some legacy appliances, older network gear, and internal systems still reject Ed25519. If you must use RSA, choose 4096 bits: ssh-keygen -t rsa -b 4096 -C "you@example.com".
• ECDSA sits in the middle but is rarely the best pick today. Unless a specific vendor requires it, Ed25519 or RSA 4096 covers everything.

Decision rule: start with Ed25519, and only fall back to RSA 4096 when a connection fails with an algorithm negotiation error.

Naming conventions that scale

After a year of work you will have several keys. Names like id_ed25519, id_ed25519_github_personal, id_ed25519_work_gitlab, and id_ed25519_prod_bastion tell you instantly which key belongs where. Vague names guarantee accidental reuse of a privileged key on a low-trust service.

One key per trust boundary

Reuse is tempting, but a key shared between a hobby project and production infrastructure means a leak in the hobby project compromises production. Creating a new pair takes seconds; recovering from an incident takes days.

Hardware-backed options

If your Mac has a Secure Enclave and you use a FIDO2 security key, you can store a key on hardware so the private material cannot be exported at all. This is the strongest option available and worth considering for administrative access to critical systems, even if the setup takes a few extra minutes.

Passphrases, ssh-agent, and Keychain integration

A passphrase turns a stolen private key file into an expensive problem instead of an instant breach. The catch is that typing it constantly is annoying, and annoyance leads people to remove it. macOS solves this cleanly.

Adding a key to the agent

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

The --apple-use-keychain flag stores the passphrase in the system Keychain so the agent can unlock the key automatically after a reboot. On older system versions the equivalent flag was -K; if one form is rejected, try the other.

Storing it in your config

Add this to ~/.ssh/config so the behavior applies automatically:

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

With that in place, the first connection after login prompts once and subsequent ones do not.

Changing a passphrase without regenerating

ssh-keygen -p -f ~/.ssh/id_ed25519

This rewrites the passphrase on the existing key. The public key and its entries on every server stay valid, so there is no re-deployment work. Rotating a passphrase every six to twelve months is a reasonable routine for administrator keys.

When to skip the passphrase entirely

Automation keys used by CI runners or deployment scripts cannot prompt for input, so they usually have no passphrase. Compensate by giving those keys the narrowest possible server-side access, restricting them with command options in authorized_keys, and storing them only in the CI provider's encrypted secret store.

GUI tools, config files, and day-to-day key management

Command line is not mandatory. Several mature apps manage the same files, which means you can switch between clicking and typing without breaking anything.

The config file is the real productivity win

~/.ssh/config lets you replace long connection strings with short aliases:

Host prod-web
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_prod
  IdentitiesOnly yes

Now ssh prod-web does everything. The IdentitiesOnly yes line is especially valuable: without it, the client offers every key the agent holds, and servers that limit authentication attempts may reject you before reaching the right key.

Desktop clients worth knowing

• Termius offers a cross-platform interface with key generation, syncing, and snippet storage. It is a good fit for people who manage many hosts.
• 1Password and similar vaults can hold keys and expose them through an agent, which is convenient for teams that already centralize secrets.
• VS Code and JetBrains IDEs read ~/.ssh/config directly, so remote development inherits your aliases.
• Apple's built-in Keychain Access is not an SSH manager, but it is where agent passphrases live, which explains the occasional system prompt after a reboot.

Housekeeping habits

Review ~/.ssh a few times a year. Delete keys for hosts you no longer use, confirm that each key file has 600 permissions, and check that known_hosts does not contain stale entries for recycled IP addresses. Ten minutes of cleanup prevents confusing failures later.

Security hardening checklist

Generate keys, then protect them. The following checklist covers the mistakes that cause most real incidents.

File permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config

OpenSSH refuses to use a private key that other users could read. If you ever see a permissions warning, fix it with the commands above rather than random experimentation.

Rotation and revocation

Replace keys every six to twelve months for privileged access, and immediately when a laptop is lost, sold, or repaired by a third party. Revocation means removing the public key line from authorized_keys on every host where it was installed; keeping a short inventory of where each key lives makes that possible in minutes.

Agent forwarding caution

Forwarding your agent lets a remote host use your local keys. If that host is compromised, so is every system your agent can reach. Prefer ProxyJump in your config to hop through a bastion without exposing the agent.

Host internal-db
  HostName 10.0.4.20
  User analyst
  ProxyJump bastion

Server-side restrictions

The authorized_keys file accepts options before the key itself, which lets you limit damage from a leaked automation key:

from="203.0.113.0/24",command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-runner

This key can only run one command from one network range, regardless of who holds it.

Auditing what is installed

On a server, list what currently has access:

awk '{print $1, $NF}' ~/.ssh/authorized_keys

Removing unknown lines is one of the fastest security improvements available on an inherited system.

Troubleshooting common macOS SSH errors

Most failures fall into a handful of categories. Working through them in order saves time.

Permission denied (publickey)

This is the catch-all message, and it almost always means one of four things: the public key is not in the server's authorized_keys, the server user is different from the one you assumed, the client offered the wrong key, or permissions on the server side are too open. Diagnose with:

ssh -v user@server.example.com

The verbose output prints each key the client offers and the server's response. If your key never appears in that list, the client is not finding it, which points back to naming and config issues.

Warnings about unprotected private key files

If SSH complains that your key is too open, run the chmod commands from the hardening section. On macOS the group staff often has read access by default on files copied from other locations.

Key not recognized after a macOS upgrade

System updates occasionally reset the Keychain state, so the agent loses cached passphrases. Re-add the key with ssh-add --apple-use-keychain and confirm that UseKeychain yes is present in your config.

Too many authentication failures

This appears when the agent offers many keys and the server allows only a few attempts. Fix it by setting IdentitiesOnly yes for the host and pointing IdentityFile at exactly one key.

Host key verification failed

You rebuilt a server, recycled an IP, or connected through a proxy that presents a different host key. Remove just that entry:

ssh-keygen -R server.example.com

Then reconnect and verify the new fingerprint with a trusted source before accepting it.

Passphrase forgotten

There is no recovery path for a forgotten passphrase. Generate a new pair, install the new public key on every host, verify access, then delete the old private key and its server entries.

Config file silently ignored

Check the syntax, since indentation and typos matter, and confirm file permissions are not so open that the client refuses to read it. Also make sure you are editing the file for the user account actually running the command. A config saved in an administrator account does not apply when you sudo into another user.

Connections hang instead of failing

Hangs usually indicate a network path problem rather than an authentication problem. Test with ssh -v to see how far the handshake progresses, check whether a VPN is required, and confirm the host is reachable with nc -vz server.example.com 22.

FAQ

What is the fastest way to generate an SSH key on a Mac?

Open Terminal and run ssh-keygen -t ed25519 -C "you@example.com", then press Return to accept the default path and enter a passphrase twice. The public key appears in ~/.ssh/id_ed25519.pub and is ready to paste into any service.

Where does macOS store SSH keys?

The default directory is ~/.ssh inside your home folder. That path is hidden in Finder, but you can reach it with Command + Shift + G and typing ~/.ssh, or by revealing hidden files.

Should I use Ed25519 or RSA?

Choose Ed25519 unless a specific system rejects it. Fall back to RSA at 4096 bits only for older hardware, appliances, or internal tools that have not added modern algorithm support.

Is it safe to use an SSH key without a passphrase?

On a laptop that leaves your home, no. Without a passphrase, the private key file is the only protection, and copying that file grants full access. For automation running on a controlled runner, an empty passphrase is a common and acceptable trade-off when the key is scoped narrowly.

How many SSH keys should I have?

One per trust boundary. A separate key for personal Git hosting, work Git hosting, production servers, and disposable test machines keeps a single compromise from cascading across everything you can reach.

How do I copy a public key to a server?

Use ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host when password login is still enabled. Otherwise paste the single line from the .pub file into ~/.ssh/authorized_keys on the remote machine.

Why does my Mac keep asking for the passphrase?

The agent is not persisting the unlock. Add the key with ssh-add --apple-use-keychain ~/.ssh/id_ed25519 and include AddKeysToAgent yes plus UseKeychain yes in ~/.ssh/config. After a system update you may need to re-add it once.

Can I use the same key for Git and server logins?

Technically yes, but it is poor hygiene. Git hosting services often display keys by comment, and a key used broadly is harder to revoke cleanly. Separate keys make audits straightforward and removals surgical.

How often should keys be rotated?

Every six to twelve months for privileged access, and immediately after any device loss, repair, resale, or suspected compromise. Rotation is only useful if you also remove the old key from every server that trusted it, which is why keeping an inventory matters.

What if I inherit a server with unknown keys installed?

List the contents of authorized_keys, review the comment at the end of each line, match entries against your team's inventory, and remove anything you cannot attribute. Then confirm you can still log in with your own key before closing the session.

Do I need a GUI client to manage keys?

No. Terminal covers every operation, including generation, passphrase changes, agent management, and removal. GUI clients are a convenience layer over the same files, which is why switching between them never requires re-creating keys.

How do I document this for a teammate?

Write a short runbook with the exact commands, then record a two- to four-minute screen capture showing a real key generation and first login. Keep the recording focused on one task, blur anything sensitive, and caption the commands so viewers can copy them accurately. Combining a written checklist with a short walkthrough video is usually faster for onboarding than either format alone.

Putting it all together

Generating an SSH key on a Mac takes seconds, but the value comes from the surrounding habits: distinct keys per trust boundary, passphrases protected by the Keychain-backed agent, a tidy ~/.ssh/config that prevents identity confusion, and periodic review of what each server trusts. Start with a single Ed25519 pair, add it to the agent, install the public half where you need access, and keep a short note about where it lives. From there, expand into hardware-backed options and authorized_keys restrictions as your responsibilities grow. Done consistently, the workflow disappears into the background, and you stop thinking about authentication entirely until the day something breaks.