SSH Keys Deep Dive: Public vs Private, How Authentication Really Works

If SSH feels confusing, it’s almost always because SSH keys feel confusing.

People often hear things like public key, private key, authorized_keys, and fingerprints, but they’re rarely explained in a way that matches how we actually use SSH day to day.

In this post, we’ll slow down and go deep—step by step—into what SSH keys really are, how authentication works, and how to use keys correctly on your laptop and servers.

No magic. No buzzwords. Just how it actually works.

1) Why SSH keys exist in the first place

Early SSH allowed password-based logins. That worked, but it had problems:

• Passwords can be guessed or brute-forced
• Passwords travel over the network (even if encrypted)
• Humans reuse weak passwords

SSH keys solve this by replacing shared secrets (passwords) with cryptographic proof.

Instead of saying:

“Here is my password, trust me.”

You say:

“I can mathematically prove I own the correct private key.”

That’s a huge security upgrade.

2) What an SSH key pair really is

When you generate an SSH key pair, you create two related keys:

• Private key → kept secret on your laptop or CI system
• Public key → shared with servers

They are linked by math, not by copying.

Important rule

The public key cannot be used to recreate the private key.

This is what makes SSH secure.

3) Generating an SSH key (try this yourself)

On your laptop, run:

ssh-keygen -t ed25519 -f ~/.ssh/example_key -C "example-key"

This creates:

~/.ssh/example_key      (private key)
~/.ssh/example_key.pub  (public key)

You can inspect the public key safely:

cat ~/.ssh/example_key.pub

Never share the private key:

cat ~/.ssh/example_key

If someone gets that file, they can authenticate as you anywhere that key is trusted.

4) What the public key actually contains

A public key looks like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM... user@laptop

It contains:

• Key type (ssh-ed25519)
• Encoded key material
• Optional comment (for humans)

The comment does nothing for security. It’s just a label.

5) Where public keys live on a server

On a Linux server, public keys live here:

~/.ssh/authorized_keys

Each line is a public key that is allowed to log in as that specific user.

That means:

• Same key + different user = different access
• Keys are tied to users, not servers

6) What actually happens during SSH authentication

Let’s say you run:

ssh -i ~/.ssh/example_key ec2-user@SERVER_IP

Behind the scenes:

1. Server asks: “Who are you?”
2. Client says: “I’m ec2-user, and I have this private key.”
3. Server checks authorized_keys
4. Server sends a cryptographic challenge
5. Client signs it using the private key
6. Server verifies the signature using the public key
7. If it matches → login succeeds

At no point does the private key leave your machine.

7) Why the server never needs your private key

A very common misconception:

“I uploaded my private key to the server.”

That should never happen.

The server only needs the public key because:

• It can verify signatures
• It cannot impersonate you
• It cannot log in elsewhere as you

If a server is compromised, attackers still don’t get your private key.

8) Why passphrases exist (and when not to use them)

You can protect a private key with a passphrase.

This means:

• Stealing the file alone is not enough
• The attacker also needs the passphrase

When to use a passphrase

• Personal laptop
• Long-lived personal keys

When NOT to use a passphrase

• CI/CD keys
• Automated deployments
• GitHub Actions

Automation cannot answer prompts.

9) Common key-related mistakes

❌ Using the wrong key

SSH may try multiple keys automatically.

Always force the correct one when debugging:

ssh -i ~/.ssh/example_key -v user@server

❌ Using the .pub file

Wrong:

ssh -i ~/.ssh/example_key.pub user@server

Correct:

ssh -i ~/.ssh/example_key user@server

Public keys never authenticate you.

❌ Copy-pasting keys with extra spaces

Always copy public keys exactly:

cat ~/.ssh/example_key.pub

One missing character breaks authentication.

10) SSH key permissions (critical)

SSH will refuse keys if permissions are unsafe.

On your laptop:

chmod 600 ~/.ssh/example_key
chmod 700 ~/.ssh

On the server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

This protects against other users reading keys.

11) How to verify which key is being used

Use verbose mode:

ssh -v user@server

Look for lines like:

Offering public key: ~/.ssh/example_key

This tells you exactly what SSH is trying.

12) A mental model that makes SSH keys click

Think of it like this:

• Public key = lock
• Private key = the only key that opens it

You give servers locks. You keep the keys.

Authentication is just proving you can open the lock.

Final thoughts

SSH keys aren’t mysterious once you understand the flow:

• Public keys declare trust
• Private keys prove identity
• The server verifies, it never trusts blindly

When SSH fails, it’s usually because:

• The wrong key is used
• The public key isn’t trusted
• Permissions are incorrect

Once you understand SSH keys deeply, debugging becomes calm and methodical—not frustrating.