Understanding SSH Keys: A Complete Practical Guide

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:

1. Prompts you for your passphrase (if set)
2. Unlocks your private key
3. Decrypts the server’s challenge
4. 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:

1. You install your special locks (public keys) on all your servers
2. You keep the master key (private key) safely with you
3. When you approach a server, it challenges you: “Prove you have the master key”
4. You unlock your master key with your passphrase, use it to prove your identity, but never hand it over
5. 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

1. Always use a passphrase on your private key
2. Use ed25519 keys (modern, fast, secure): ssh-keygen -t ed25519
3. Generate separate keys for different purposes (personal, work, high-security systems)
4. Regularly audit your authorized_keys files on servers
5. Remove old keys when you decommission devices

For Convenience

1. Use ssh-agent to avoid typing your passphrase repeatedly
2. Create an SSH config file to simplify connection commands
3. 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.