Why I Stopped Using One Single SSH Key for GitHub (And You Probably Should Too)

For the longest time I was doing what most people do when they start out with Git and GitHub. One SSH key, doing everything. Pushing code, pulling repos, signing commits, all from the same pair of files sitting quietly in my .ssh folder. It worked fine. Never gave me trouble. So I never really questioned it.

Then one day I was reading through GitHub’s docs for something completely unrelated, and I noticed they actually let you register two different types of SSH keys. One for authentication, and one purely for signing commits. That small detail stuck with me, and honestly it took me a weekend project to actually sit down and understand why this separation even exists in the first place.

So here’s what I learned, and how I set it up on my own machine. If you’re someone who has multiple GitHub accounts, contributes to open source, or just wants your commit history to look a bit more trustworthy with that green “Verified” tag, this is worth doing.

First, the confusion: authentication and signing are not the same thing

I used to think SSH keys on GitHub had one job, prove it’s you. Turns out that’s only half true.

Authentication is about access. When you clone, pull or push a repo, GitHub needs to confirm that the machine talking to it actually belongs to you. That’s what your regular SSH key handles.

Signing is about trust in your commits, not your access. Anyone who has your repo cloned locally can technically create a commit and put your name and email on it in the author field. That doesn’t mean you wrote it. Signing solves that. When a commit is signed with your private key, GitHub can verify the signature and show that little “Verified” badge next to it, which basically tells other developers this commit genuinely came from you and not from someone spoofing your identity.

Two very different jobs. So I figured, why should one single key be responsible for both?

The setup I ended up going with

After going back and forth, here’s the folder structure I landed on inside ~/.ssh/:

~/.ssh/

id_ed25519_personal
id_ed25519_personal.pub

id_ed25519_personal_signing
id_ed25519_personal_signing.pub

config

Two separate key pairs. One purely handles GitHub access, the other purely handles commit signatures. Nothing overlaps.

Step 1: Creating the authentication key

I went with Ed25519 since it’s what’s generally recommended these days over the older RSA keys, it’s faster and just as secure with a much shorter key length.

ssh-keygen -t ed25519 -C "contact@devnotes.example" -f ~/.ssh/id_ed25519_personal

It’ll ask you to set a passphrase during creation. Don’t skip this part out of laziness like I almost did. A passphrase means that even if somehow your private key file ends up in the wrong hands, it’s still useless without that phrase. Small extra step, real difference in security.

Once done, you’ll have two files:

id_ed25519_personal
id_ed25519_personal.pub

The .pub file is your public key, the one you're allowed to share anywhere. The other file, without the .pub extension, is your private key. That one never leaves your machine, never gets pasted anywhere, never gets emailed to anyone, no exceptions.

Step 2: Adding it to GitHub

Copy the public key to your clipboard:

cat ~/.ssh/id_ed25519_personal.pub

Head over to GitHub, go to Settings → SSH and GPG keys → New SSH key, paste it in, and this is the part people usually miss, make sure you select:

Key type: Authentication Key

Once it’s added, test the connection:

ssh -T git@github-personal

If everything’s set up correctly you’ll see something like:

Hi yourusername! You've successfully authenticated, but GitHub does not provide shell access.

That message is basically GitHub telling you “yep, I know who you are now.”

Step 3: Setting up the SSH config file

This part is what actually ties everything together, especially useful if you’re juggling more than one GitHub identity (say a personal account and a work account). Open or create:

~/.ssh/config

And add this block:

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

That IdentitiesOnly yes line looks tiny but it matters a lot. Without it, SSH tends to just try every single key it finds in your .ssh folder one by one until something sticks, which gets messy fast once you have multiple keys lying around. With this line, SSH is told explicitly, "only use the key I'm pointing you to, don't go guessing."

Step 4: Creating a separate key just for signing

Now for the second key, the one that has nothing to do with logging into GitHub and everything to do with proving your commits are genuinely yours.

ssh-keygen -t ed25519 -C "contact@devnotes.example" -f ~/.ssh/id_ed25519_personal_signing

This gives you another pair:

id_ed25519_personal_signing
id_ed25519_personal_signing.pub

Take the public half back to GitHub’s SSH key settings, add it again, but this time choose:

Key type: Signing Key

Yes, you’re allowed to add multiple keys under the same account as long as you pick the right type for each one.

Step 5: Telling Git to actually use it for signing

By default Git assumes you’re using GPG for signing, so we need to switch that over to SSH format:

git config --global gpg.format ssh

Then point Git to your new signing key:

git config --global user.signingkey ~/.ssh/id_ed25519_personal_signing.pub

From here you can sign commits manually one at a time:

git commit -S -m "First signed commit, finally"

Or, if like me you’d rather not remember to add -S every single time, just make it automatic for every commit going forward:

git config --global commit.gpgsign true

Now every commit you make carries your digital signature without you having to think about it.

Making sure it actually worked

Locally, you can double check with:

git log --show-signature

And once you push it up, GitHub will show a Verified badge right next to the commit in the repo history. That badge is basically GitHub’s way of confirming to anyone browsing the repo that this commit is authentically yours and hasn’t been tampered with or spoofed.

Was this actually worth the extra setup?

Honestly, for a lot of casual personal projects, no one’s going to notice or care whether your commits are signed. But once you’re contributing to open source, working with a team, or just care about your GitHub profile looking legitimate and professional, this small separation between “who can access my repos” and “who can prove a commit came from me” starts to matter a lot more.

Here’s roughly how the two pieces fit together once it’s all set up:

SSH Authentication Key
        |
        v
GitHub Access (clone / pull / push)

SSH Signing Key
        |
        v
Commit Verification (Verified badge)

Two keys, two jobs, no overlap. It took me maybe twenty minutes total to set this up properly, and now I don’t really have to think about it again. If you’ve been putting off doing this on your own setup, honestly it’s a pretty painless afternoon task and one of those things that quietly makes your whole workflow feel a bit more solid.