Private or Public Key? I Was Confused Too — Here’s the Difference!

Photo by Jason Mavrommatis on Unsplash

When I first started working with SSH keys, I received a file called something.pem from a client. Naturally, I assumed this was the server’s private key. After all, it was labeled as a "private key," and it came from the client. But as I learned more about SSH authentication, I realized I was completely wrong.

The .pem file wasn’t the server’s private key—it was the client’s private key, given to me to access the server. This small but important distinction cleared up a lot of confusion, and I’d like to explain how SSH keys really work.

Understanding Private and Public Keys

The concept of private and public keys can be confusing at first, but here’s a simple breakdown:

Public Key:

• Think of this as the lock you place on the server.
• It’s stored in the server’s ~/.ssh/authorized_keys file.
• Anyone with the matching private key can use it to “unlock” access.

Private Key:

• This is the key to that lock.
• It stays on your local machine and is never shared with anyone — not even the server.
• It’s used to prove your identity when you try to access the server.

How Public-Private Keys Work Together

Here’s how the system works in practice:

1. You Create the Keys: You generate a pair of keys — a public key and a private key — on your local machine.
2. Public Key Goes to the Server: You (or the client) upload the public key to the server, where it’s added to the authorized_keys file.
3. Private Key Stays with You: When you try to connect to the server, your private key is used to encrypt a message.
4. The Server Validates You: The server uses the matching public key to decrypt your message. If it matches, you’re authenticated without needing a password.

The Process: Client Gives Private Key vs. You Give Public Key

Here are two scenarios for how SSH access is typically set up:

Scenario 1: The Client Gives You the .pem File

What Happens:

• The client generates the keys on their system.
• They keep the public key on the server and send the private key (.pem) to you.

Your Steps:

• Save the .pem file securely on your machine (e.g., in ~/.ssh/).
• Use the private key to connect to the server:

ssh -i ~/.ssh/something.pem username@server-ip

• While this works, it’s less secure because sharing private keys introduces risks.

Scenario 2: You Generate Your Own Keys and Give the Public Key to the Client

Get Muchamad Faiz’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This approach is more secure and is the recommended method. Here’s how it works:

1. Generate Keys on Your Local Machine: Run the following command to create a pair of keys:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

This creates two files:

• ~/.ssh/id_rsa: Your private key (keep this secure).
• ~/.ssh/id_rsa.pub: Your public key (to share with the client).

2. Send the Public Key to the Client: Copy the contents of the public key file:

cat ~/.ssh/id_rsa.pub

Share this with the client via a secure method (e.g., email or file transfer).

3. The Client Adds Your Public Key to the Server: The client logs into the server and adds your public key to the authorized_keys file:

echo "your-public-key-content" >> ~/.ssh/authorized_keys

4. You Connect Using Your Private Key: Once your public key is on the server, you can connect using your private key:

ssh -i ~/.ssh/id_rsa username@server-ip

The Confusion with .pem Files

Here’s where my initial confusion came in: when the client gave me the .pem file, I thought it was the server’s private key. In reality, the .pem file was my private key, and the server already had the matching public key in its authorized_keys.

It’s easy to see how this can be misunderstood, especially when you’re new to SSH. But the takeaway is clear: the private key belongs to the user, not the server.

Key Takeaways

1. The Public Key is Stored on the Server:

• It identifies which users are allowed to connect.
• Stored in the authorized_keys file.

1. The Private Key is Stored on Your Local Machine:

• It’s your personal “proof of identity.”
• Never share your private key with anyone — not even the client.

1. Best Practices:

• Always generate your own key pair locally using ssh-keygen.
• Share only the public key with the client or upload it to the server yourself.
• Protect your private key with proper permissions (chmod 400) and avoid uploading it to the server.

Conclusion

Understanding the difference between private and public keys in SSH is crucial for secure server management. While it’s common for clients to share their private keys, a better and more secure approach is for you to generate your own key pair and share the public key.

Remember:

• Public keys are placed on the server.
• Private keys stay with the user.
• Avoid sharing private keys whenever possible to maintain strong security.

If you’ve ever been confused by SSH keys, don’t worry — you’re not alone. Hopefully, this clears up the mystery for you, too!