Demystifying SSH Key Pairs: The Silent Guardians of Modern Infrastructure

Every DevOps engineer has typed this command countless times:

ssh ubuntu@my-server

A few seconds later, you're inside a Linux machine located hundreds or thousands of miles away.

No password.
No magic.
Just cryptography quietly doing its job.

SSH key pairs have become so common that many engineers stop questioning how they actually work. Yet these tiny files are responsible for securing cloud infrastructure, deployment pipelines, Git repositories, Kubernetes nodes, automation tools, and production servers across the world.

Understanding what's happening behind the scenes doesn't just satisfy curiosity—it makes you a better engineer who can troubleshoot authentication issues, design secure infrastructure, and avoid dangerous security mistakes.

Let's open the black box.

The Lock-and-Key Analogy: Understanding Asymmetric Cryptography

Forget complex mathematics for a moment.

Imagine your production server has a special lock installed on its front door.

Anyone is allowed to see the lock.
Anyone can even make a copy of the lock.

But only one unique key can unlock it.

That's exactly how SSH authentication works.

The mapping is surprisingly simple:

• Public Key → Stored on the server
• Private Key → Stored only on your computer

Think of the public key as a lock that's intentionally visible.

The private key is the only object capable of proving you own that lock.

The most important rule is simple:

You can share your public key with the world. You should never share your private key.

If someone obtains your private key, they can impersonate you exactly as if they had stolen your house key.

Quick Takeaway

• Public Key = The lock
• Private Key = The secret key
• Locks are meant to be public.
• Keys must remain private.

What Actually Happens During an SSH Connection?

One of the biggest misconceptions is that your computer sends the private key to the server.

It never does.

If it did, SSH would be fundamentally insecure.

Instead, SSH uses a challenge-response authentication protocol.

Let's walk through the entire handshake.

Step 1 — The Client Knocks

You run:

ssh ubuntu@server

Your client simply says:

"I'd like to authenticate."

The server now checks:

"Do I recognize this user?"

It looks inside:

~/.ssh/authorized_keys

If your public key isn't present, authentication immediately fails.

Step 2 — The Server Creates a Challenge

Rather than asking for a password, the server generates a completely random challenge.

Think of it like this:

"If you really own the private key, prove it."

Every challenge is unique.

This prevents replay attacks.

Step 3 — Your Private Key Signs the Challenge

Here's the clever part.

The challenge is processed locally by your private key.

Your computer creates a digital signature.

Only the signature is sent back.

The private key never leaves your machine.

Not once.

Step 4 — The Server Verifies the Signature

The server already possesses your public key.

Using that public key, it verifies the signature.

If verification succeeds:

Authentication Successful

Otherwise:

Permission denied (publickey)

This entire process usually completes in milliseconds.

Why Is This Better Than Passwords?

Notice what never happened.

• Your password never crossed the network.
• Your private key never left your laptop.
• The server never learned your secret.

Even if someone captured every packet travelling across the internet, they still couldn't authenticate as you.

That's why SSH keys are dramatically safer than password authentication.

What's Actually Inside an SSH Key File?

SSH keys often look mysterious because they're long strings of random-looking characters.

They're not random.

They're structured cryptographic data encoded in a portable format.

Let's break them apart.

Public Key

Example:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF2.... developer@laptop

This file contains three sections.

1. Algorithm Identifier

ssh-ed25519

or

ssh-rsa

This tells SSH which cryptographic algorithm generated the key.

2. Base64-Encoded Cryptographic Data

AAAAC3NzaC1lZDI1...

This isn't encrypted text.

It's Base64-encoded binary data representing the mathematical public key.

Base64 simply converts binary bytes into printable ASCII characters so they can safely live inside text files.

3. Comment

developer@laptop

This is only a label.

It helps humans identify the owner.

SSH ignores it during authentication.

Private Key (.pem or OpenSSH Format)

Example:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAA...
...
-----END OPENSSH PRIVATE KEY-----

Inside this file you'll find:

• Private cryptographic numbers
• Algorithm metadata
• Optional passphrase encryption metadata
• Base64-encoded binary content

This file is effectively your digital identity.

Treat it exactly like your passport or house keys.

Quick Takeaway

SSH key files are not random text. They're structured cryptographic information encoded using Base64 so operating systems and applications can store them as ordinary text files.

The 4 Types of SSH Key Pairs

Not all SSH keys are created equal.

Over the years, multiple cryptographic algorithms have been used for SSH authentication. Some are modern and highly secure, while others are now considered legacy.

Here's how they compare.

1. Ed25519 — The Modern Gold Standard

Ed25519 is the newest and most widely recommended SSH algorithm.

Why engineers love it:

• Small key size
• Extremely fast authentication
• Faster key generation
• Strong resistance against implementation mistakes
• Excellent security
• Compact public keys

Although the key is only 256 bits, elliptic curve cryptography provides security comparable to much larger RSA keys.

For nearly every modern Linux distribution, cloud platform, and Git provider, Ed25519 should be your default choice.

2. RSA — The Universal Titan

RSA has protected internet communications for decades.

It's supported almost everywhere.

Older systems still rely heavily on RSA because of its unmatched compatibility.

However, security recommendations have evolved.

Today:

• 2048-bit RSA is still acceptable in many environments.
• 4096-bit RSA is commonly preferred for stronger long-term security.

The trade-off is larger keys, slower signatures, and higher computational overhead compared to Ed25519.

RSA remains an excellent compatibility option when interacting with legacy systems.

3. ECDSA — Elliptic Curve Alternative

ECDSA also uses elliptic curve cryptography.

Advantages:

• Smaller keys
• Faster than RSA
• Good security

However, ECDSA relies on NIST-defined curves, which some organizations prefer to avoid due to historical concerns around parameter generation.

It's still secure and widely supported, but Ed25519 has largely become the preferred elliptic curve implementation for SSH.

4. DSA — Legacy Only

DSA was once common.

Today it is effectively obsolete.

Most modern OpenSSH implementations disable DSA entirely because:

• Fixed 1024-bit keys
• Weak by modern standards
• No longer recommended
• Poor compatibility with current security policies

If you still find DSA in production, it's time to migrate.

Verdict

If you're generating a brand-new SSH key today:

Choose Ed25519 unless you specifically need RSA for compatibility with older systems.

It offers the best balance of:

• Security
• Speed
• Simplicity
• Small key size
• Broad modern support

SSH Keys: The Backbone of Modern Infrastructure

SSH isn't just for logging into Linux servers.

It's one of the foundational trust mechanisms behind modern DevOps.

1. Cloud VM Provisioning

When creating a virtual machine in AWS, Azure, or Google Cloud, you'll typically upload a public SSH key during provisioning.

The cloud platform automatically writes it into:

~/.ssh/authorized_keys

As soon as the VM boots, you can securely connect without ever configuring a password.

2. Configuration Management

Tools like Ansible use SSH to manage fleets of servers.

Instead of entering passwords hundreds of times, Ansible authenticates using SSH keys and executes tasks across dozens—or even thousands—of machines simultaneously.

Without SSH keys, large-scale infrastructure automation simply wouldn't be practical.

3. CI/CD Pipelines

Deployment pipelines also rely on SSH keys.

Whether you're using:

• GitHub Actions
• Azure DevOps
• GitLab CI/CD
• Jenkins

your pipeline often needs to:

• deploy applications
• copy build artifacts
• execute remote commands
• configure production servers

SSH keys provide secure, non-interactive authentication that automation can trust.

4. Git Workflows

Every time you run:

git clone
git pull
git push

your Git provider may authenticate you using SSH keys.

This eliminates repeated password prompts while providing stronger authentication than traditional username/password combinations.

Security Risks You Should Never Ignore

SSH keys are incredibly secure.

Poor handling of those keys is not.

Risk 1 — Local Malware

If malware steals your private key:

id_ed25519

or

production.pem

an attacker may be able to authenticate as you.

Protect yourself by:

• Using a strong passphrase
• Encrypting your disk
• Keeping operating systems patched
• Using hardware-backed security where possible
• Rotating compromised keys immediately

Risk 2 — Accidentally Committing Keys to Git

One accidental command:

git add .
git commit
git push

can expose your private key forever.

Even if you later delete the file, it still exists in Git history.

If this happens:

1. Assume the key is compromised.
2. Remove the public key from every server.
3. Generate a new key pair.
4. Replace every affected deployment.

Never assume deleting the latest commit is enough.

Risk 3 — Sharing One .pem File Across a Team

This is one of the worst anti-patterns in infrastructure management.

Imagine a shared file:

production.pem

living in:

• Shared drives
• Slack
• Teams
• Email attachments

Now everyone uses the same identity.

Problems include:

• No accountability
• No individual audit trail
• Impossible access tracking
• Painful offboarding
• Massive blast radius if the key leaks

One compromised laptop now compromises your entire production environment.

The Right Way: One User, One Key

Professional infrastructure teams follow a simple rule:

One User. One SSH Key Pair.

Every engineer generates their own private/public key pair.

The server simply stores multiple public keys inside:

~/.ssh/authorized_keys

Example:

ssh-ed25519 AAAA... alice@laptop
ssh-ed25519 AAAA... bob@desktop
ssh-ed25519 AAAA... charlie@macbook

Now everyone can authenticate independently.

If Bob leaves the company?

Delete Bob's public key.

Everyone else keeps working uninterrupted.

This approach provides:

• Individual accountability
• Easier auditing
• Simple onboarding
• Clean offboarding
• Reduced security risk
• Better compliance

Best Practices Checklist

• ✅ Generate Ed25519 keys for new systems whenever possible.
• ✅ Keep your private key on your own device.
• ✅ Protect private keys with a strong passphrase.
• ✅ Never commit private keys to Git.
• ✅ Never share .pem files between team members.
• ✅ Use one SSH key pair per person.
• ✅ Regularly review and clean up authorized_keys.
• ✅ Rotate keys immediately after suspected compromise.

Closing Thoughts

SSH key pairs are one of the quiet heroes of modern infrastructure. They secure cloud virtual machines, enable large-scale automation, authenticate Git operations, and power countless CI/CD deployments—all without sending passwords across the network.

The concept is beautifully simple: the server exposes a lock (the public key), while you keep the only matching key (the private key). During authentication, your machine proves it owns that key through a cryptographic challenge-response process, never revealing the secret itself.

The next time you run:

ssh ubuntu@production-server

remember that behind that simple command is decades of carefully engineered cryptography, silently protecting the systems we rely on every day.