You signed up for a hosting service. You're ready to deploy your app. Then a box
pops up: "Paste your SSH public key."

And you freeze. What key? Where is it? Is it safe to paste? Did I just leak
something I shouldn't?

Take a breath. By the end of this post you'll know exactly what an SSH key is,
why there are two of them, and what to paste (and what to never, ever paste).
You'll get it so well you could teach a friend.

The idea in one line

An SSH key is a pair of files that lets you prove who you are to a server,
without typing a password.

The metaphor: a padlock and its only key

Think of a public key as a padlock. You can make a thousand copies of it and
hand them out to anyone. Servers, friends, GitHub, your hosting provider. It's
fine. A padlock locked shut is useless to a stranger.

Think of the private key as the one real key that opens those padlocks.
There is only one, it lives on your computer, and you never give it away. Ever.

PUBLIC KEY  =  a padlock        -> share it freely
PRIVATE KEY =  the only key     -> keep it secret, keep it safe

So when a server wants to know "are you really you?", it puts a message inside a
box, locks it with your padlock (public key), and tosses it over. Only your real
key (private key) can open it. You open it, prove you can, and you're in.

The magic part: your private key never leaves your machine. The server only
ever sees the padlock.

How it actually works (the short version)

You                                  Server
 |                                      |
 | "Hi, I'm Alex"     ----------------> |
 |                                      |  finds your padlock (public key)
 |                                      |  locks a random message with it
 | <----------------  here's a puzzle   |
 |                                      |
 | unlock it with my                    |
 | private key, send proof  ----------> |
 |                                      |  proof checks out
 | <----------------  welcome in!       |
 |                                      |

You never send your private key across the internet. You only send proof that
you own it. That's why SSH keys are way safer than passwords. A password gets
typed and sent; a private key just stays home and answers puzzles.

Making your keys (the part you actually do)

Open a terminal and run this one command:

ssh-keygen -t ed25519 -C "you@example.com"

• ssh-keygen is the tool that makes the key pair.
• -t ed25519 picks a modern, strong key type. (If a service complains it's too old to support it, use -t rsa -b 4096 instead.)
• -C "..." is just a label, usually your email, so you remember whose key it is.

It will ask where to save and for an optional passphrase. Press Enter to accept
the defaults. When it's done, you have two new files:

~/.ssh/id_ed25519        <- PRIVATE key. secret. never share.
~/.ssh/id_ed25519.pub    <- PUBLIC key. the .pub one is safe to share.

See that .pub? That tiny detail saves people. The file ending in .pub is
the public one. That is the one you paste into hosting dashboards.

"The host wants my SSH key": what to actually paste

When a hosting service, GitHub, or a server asks for "your SSH key," they almost
always mean your public key. Here's how to grab it safely:

cat ~/.ssh/id_ed25519.pub

You'll see something like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID...a bunch of characters... you@example.com

Copy that whole line and paste it into the box. Done. That's the padlock. It is
meant to be shared, so pasting it is totally safe.

The box says "SSH key"?
        |
        v
Paste the file that ends in  .pub      [ OK ]   yes
Paste the file with NO .pub            [STOP]   NEVER (that's your private key)

If you ever open a file and the very first line says
-----BEGIN OPENSSH PRIVATE KEY-----, stop. That's the private one. Close it
and grab the .pub file instead.

A real case: deploying with git push

Say you set up your public key on your hosting provider. Now you can do this:

git push production main

No password prompt. No "enter your credentials." It just works, because your
machine quietly proves it owns the matching private key. That smooth, password-free
deploy you've seen senior devs do? This is the whole trick.

Same thing with connecting to a server directly:

ssh user@your-server.com
# you're in, no password typed

Gotchas juniors hit

1. Pasting the private key by mistake.
If you ever paste a key and it starts with -----BEGIN ... PRIVATE KEY-----, you
pasted the wrong file. Treat that key as burned: generate a new pair and replace
it everywhere.

2. Thinking you need a new key for every service.
You don't. One public key can go on GitHub, your host, and ten servers at once.
It's a padlock. Copies are fine.

3. Wrong file permissions.
SSH is picky for your safety. If it refuses your key, tighten the permissions:

chmod 600 ~/.ssh/id_ed25519        # private key: only you can read it
chmod 644 ~/.ssh/id_ed25519.pub    # public key: readable is fine

4. Forgetting to back up the private key.
If you wipe your laptop without saving ~/.ssh/, that key is gone. You're not
locked out forever (just make a new pair and re-add the public key everywhere),
but it's annoying. Keep a safe backup.

Recap

• An SSH key is a pair: a public key (padlock) and a private key (the only key).
• Share the public key freely. It's the file ending in .pub.
• Never share the private key. It stays on your machine and just answers puzzles.
• When a host asks for "your SSH key," paste the .pub file. That's it.
• Result: secure, password-free logins and deploys.

Your turn

Run ssh-keygen -t ed25519 on your machine, then run
cat ~/.ssh/id_ed25519.pub. Look at the two files you made. Which one would you
paste into a hosting dashboard, and which one would you guard with your life?

If you can answer that out loud, you've got it. Now go teach a friend.