SSH keys are one of the most secure and convenient ways to authenticate with remote servers. Whether you’re a developer accessing cloud servers, a DevOps engineer automating deployments, or a system administrator managing infrastructure, understanding how SSH keys work is essential.
This guide breaks down everything you need to know about SSH public and private keys—from basic concepts to practical implementation on macOS.
What Are SSH Keys?
SSH keys come in pairs, and each key serves a specific purpose:
- Public Key — Safe to share openly. Think of it as a lock you place on servers you want to access.
- Private Key — Must be kept secret. This is your master key that opens those locks.
- Passphrase — An optional password that encrypts your private key locally for extra security.
These keys work together to enable secure, password-free authentication to remote servers.
Why Do We Need Public Keys?
Your public key serves as your identity verification mechanism on remote servers. Here’s why it matters:
Security Benefits
- No password transmission — Your password never travels across the internet
- Phishing protection — Even if someone tricks you, they can’t steal your private key remotely
- Brute-force resistance — Impossible to guess or crack through repeated attempts
- Audit trails — Servers can log which key was used for each access
Practical Benefits
- Automation — Scripts and CI/CD pipelines can authenticate without human intervention
- Multiple server access — One key pair can unlock dozens or hundreds of servers
- No password management — No need to remember or rotate passwords for each server
In essence: The public key is the lock the server uses to trust your private key.
How SSH Authentication Works: The Complete Flow
Let’s walk through exactly what happens when you SSH into a server.
Initial Setup
Step 1: Server Configuration
Your public key gets added to the server’s authorized keys file:
~/.ssh/authorized_keys
This is typically done once during initial setup.
Step 2: Local Key Storage
Your private key stays on your Mac:
~/.ssh/id_ed25519
Protected by your passphrase (if you set one).
The Authentication Dance
Step 3: Connection Request
You initiate the connection:
ssh user@server.example.com
Step 4: Server Challenge
The server finds your public key in authorized_keys and creates a challenge. It encrypts a random piece of data using your public key and sends it to your computer.
Step 5: Private Key Response
Your SSH client:
- Prompts you for your passphrase (if set)
- Unlocks your private key
- Decrypts the server’s challenge
- Sends the decrypted answer back
Step 6: Verification
The server verifies the response. If it matches what only your private key could produce, you’re granted access.
The Critical Security Feature
Your private key never leaves your device. The server never sees it, network traffic never contains it, and no one intercepting your connection can capture it.
Understanding the Email in Your Public Key
When you generate SSH keys, you’ll often see a command like this:
ssh-keygen -t ed25519 -C "you@example.com"
The email address is simply a comment label—it’s not part of the cryptographic material. It serves one purpose: helping you identify which key is which when you have multiple keys.
When you view your public key:
cat ~/.ssh/id_ed25519.pub
You’ll see something like:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJfT... you@example.com
The email at the end is just metadata for your convenience.
Key Storage on macOS
Default Locations
Your SSH keys live in the .ssh directory in your home folder:
- Private key:
~/.ssh/id_ed25519 - Public key:
~/.ssh/id_ed25519.pub - Config file:
~/.ssh/config(optional) - Known hosts:
~/.ssh/known_hosts
Viewing Your Keys
List all SSH files:
ls -la ~/.ssh
View your public key (safe to share):
cat ~/.ssh/id_ed25519.pub
View your private key (never share):
cat ~/.ssh/id_ed25519
Open the SSH folder in Finder:
open ~/.ssh
File Permissions Matter
macOS (and SSH) require specific permissions for security:
# Private key: readable only by you
chmod 600 ~/.ssh/id_ed25519
# Public key: readable by everyone
chmod 644 ~/.ssh/id_ed25519.pub
# SSH directory: accessible only by you
chmod 700 ~/.ssh
If permissions are wrong, SSH will refuse to use your keys.
Copying Keys Between Macs
Can You Do It?
Public key: Absolutely. Copy it anywhere—it’s meant to be shared.
Private key: Yes, but with important caveats.
When You Should Copy Your Private Key
- Setting up a new Mac
- Maintaining access across multiple personal devices
- Recovering from a backup
How to Copy Safely
Step 1: Copy both files
# On old Mac
scp ~/.ssh/id_ed25519* newmac@192.168.1.100:~/.ssh/
# Or use a secure USB drive
cp ~/.ssh/id_ed25519* /Volumes/SecureDrive/
Step 2: Set correct permissions on new Mac
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 700 ~/.ssh
Step 3: Test the key
ssh user@yourserver.com
Security Considerations
When you copy your private key:
- Anyone who gets that key can access your servers
- Consider generating new keys instead if security is critical
- Use a strong passphrase to add an extra protection layer
- Never email or upload private keys to cloud services
- Consider using separate keys for different security contexts
The Role of Passphrases
Your passphrase is a local security measure that many users misunderstand.
What Passphrases Do
- Encrypt your private key on your device
- Prevent unauthorized use if someone gains physical access to your Mac
- Add a second factor (something you have + something you know)
What Passphrases Don’t Do
- ❌ Encrypt your public key (it’s meant to be public)
- ❌ Get transmitted to servers during authentication
- ❌ Participate directly in the cryptographic handshake
- ❌ Protect your key if it’s stolen and the thief has the passphrase
Using ssh-agent
macOS includes ssh-agent, which remembers your passphrase during a session:
# Add key to agent
ssh-add ~/.ssh/id_ed25519
# List loaded keys
ssh-add -l
# Remove all keys from agent
ssh-add -D
On modern macOS, you can store the passphrase in Keychain:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
The Ultimate Analogy
Think of SSH keys like a physical security system:
- Public key = A special lock you install on every server you need to access
- Private key = The master key that opens all those locks
- Passphrase = A small lock protecting your master key when it’s in your pocket
The workflow:
- You install your special locks (public keys) on all your servers
- You keep the master key (private key) safely with you
- When you approach a server, it challenges you: “Prove you have the master key”
- You unlock your master key with your passphrase, use it to prove your identity, but never hand it over
- The server verifies you have the right key and grants access
The beauty of this system: Your master key never leaves your possession.
Best Practices
For Maximum Security
- Always use a passphrase on your private key
- Use ed25519 keys (modern, fast, secure):
ssh-keygen -t ed25519 - Generate separate keys for different purposes (personal, work, high-security systems)
- Regularly audit your
authorized_keysfiles on servers - Remove old keys when you decommission devices
For Convenience
- Use ssh-agent to avoid typing your passphrase repeatedly
- Create an SSH config file to simplify connection commands
- Use descriptive comments in your keys to identify them later
Example SSH Config
Create ~/.ssh/config:
Host myserver
HostName server.example.com
User myusername
IdentityFile ~/.ssh/id_ed25519
Host github
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
Now you can simply type: ssh myserver
Common Issues and Solutions
“Permission denied (publickey)”
Causes:
- Your public key isn’t in the server’s
authorized_keys - Wrong file permissions on server or local keys
- Wrong username
Fix:
# Check which key is being offered
ssh -v user@server
# Copy your public key to server
ssh-copy-id user@server
“Bad permissions” Error
Fix:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
Key Not Being Used
Fix: Specify the key explicitly:
ssh -i ~/.ssh/id_ed25519 user@server
Or add it to ssh-agent:
ssh-add ~/.ssh/id_ed25519
Conclusion
SSH keys are remarkably elegant: a public key you can share with the world, and a private key that never leaves your device. Together, they provide authentication that’s both more secure and more convenient than passwords.
The key takeaways:
- Public keys go on servers (the locks)
- Private keys stay with you (your master key)
- Passphrases protect your private key locally
- The authentication happens through cryptographic proof, not by sending secrets
- Proper file permissions are critical for security
Whether you’re deploying code, managing servers, or just connecting to a Raspberry Pi at home, SSH keys are your secure gateway to remote systems.
Ready to create your first SSH key?
ssh-keygen -t ed25519 -C "your@email.com"
Follow the prompts, set a strong passphrase, and you’re on your way to secure, password-free authentication.
