Verifying Your GitHub Commits with GPG or SSH

Verifying Your GitHub Commits with GPG or SSH

Infrastructure, Ansible, AWS, Home Lab

If you’ve been following along with the previous posts on managing multiple Git identities and multiple SSH keys, this next step adds a nice layer of polish — verified commits.

You’ve probably noticed some commits on GitHub have a little “Verified” badge next to them.
That badge tells others (and your future self) that GitHub has confirmed the commit really came from you — not someone impersonating your name and email.

Let’s walk through how to set up commit signing for your personal and work Git accounts.


🧩 Why Sign Commits?

Git already tracks who made each commit, but those details (name and email) are easy to fake — they’re just text in your config.

Signing your commits adds cryptographic proof that they actually came from you.

Benefits:

  • ✅ Verified commits on GitHub
  • 🧠 Stronger identity assurance for open-source work
  • 🔒 Prevents impersonation or accidental misattribution

🔐 Two Ways to Sign Commits

GitHub supports two signing methods:

  1. GPG (GNU Privacy Guard) – traditional, widely supported
  2. SSH signing – newer and simpler (especially if you already use SSH keys)

We’ll go through both, starting with SSH since it’s the easiest to set up.


⚙️ Option 1 – Signing Commits with SSH

If you already have SSH keys for GitHub (from Part 2), you can use them to sign commits.

1. Check your Git version

SSH commit signing requires Git 2.34+:

git --version

If it’s older, update it before continuing.

2. Tell Git to use SSH signing

Pick which key you want to use (personal or work) and set it as the signing key:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519_personal.pub
git config --global commit.gpgsign true

If you use separate identities, you can set the signing key per directory using the same includeIf setup from earlier:

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

And inside ~/.gitconfig-work:

[gpg]
    format = ssh
[user]
    signingkey = ~/.ssh/id_ed25519_work.pub

3. Add the public key to GitHub

Copy your SSH public key:

cat ~/.ssh/id_ed25519_personal.pub

Go to GitHub → Settings → SSH and GPG keys → New SSH key,
then choose "Signing Key" as the type.

Once saved, any commit signed with that SSH key will show up as Verified on GitHub.


🔑 Option 2 – Signing Commits with GPG

If you prefer GPG, or already use it for encryption, you can generate and add a GPG key instead.

1. Generate a GPG key

gpg --full-generate-key

Choose:

  • Key type: RSA and RSA
  • Key size: 4096
  • Expiration: up to you
  • Real name & email: must match your Git config

Then list your keys:

gpg --list-secret-keys --keyid-format=long

2. Set your signing key in Git

Take the long key ID (the part after sec rsa4096/) and configure Git:

git config --global user.signingkey YOURKEYID
git config --global commit.gpgsign true

3. Add your public key to GitHub

Export your public key:

gpg --armor --export YOURKEYID

Copy the output and add it at
GitHub → Settings → SSH and GPG keys → New GPG key

That’s it — your GPG-signed commits will now show as verified too.


🧠 Testing It

Make a test commit:

git commit -S -m "test signed commit"

Push it to GitHub, then open the commit in your repo — you should see:

✅ Verified

For example, when enabled on GitHub it should look like this, see previous Unverified and then subsequent Verified commit.

If you don’t, check that:

  • The key email matches your GitHub account email
  • The right key was added as a signing key
  • You’re not committing as a different user/SSH alias

🧩 Bonus Tip – Visual Verification

You can confirm locally that commits are signed and valid:

git log --show-signature

This will show which key signed each commit.


✅ Summary

You’ve now got:

  • Part 1: 🔄 Automatic author switching per directory
  • Part 2: 🔑 SSH key separation for multiple Git accounts
  • Part 3 (This post): 🪪 Verified commits on GitHub

Together, these make your Git setup more professional, secure, and organised — whether you’re working across open-source, side projects, or enterprise repos.