Demystifying GitHub SSH Commit Verification: A Key Insight for GitHub Code Review Analytics

In the world of software development management, ensuring the integrity and authenticity of code commits is paramount. GitHub's commit verification feature, particularly with SSH keys, is a powerful tool for this. However, a recent discussion on the GitHub Community forum highlighted a common pitfall that can lead to SSH-signed commits showing as "Unverified," even when developers believe everything is correctly configured. This insight from Discussion #185945 sheds light on the subtle but crucial distinction GitHub makes for SSH keys.

A 'Verified' commit badge on GitHub, symbolizing secure code integrity.
A 'Verified' commit badge on GitHub, symbolizing secure code integrity.

The Challenge: When "Verified" Isn't Verified

Jorge-de-la-Flor, a developer using WSL (Ubuntu), encountered a perplexing issue: his SSH-signed commits were consistently marked "Unverified" on GitHub. His setup seemed impeccable:

  • Git was globally configured to sign commits with SSH.
  • His public SSH key (id_ed25519.pub) was correctly registered on GitHub under "Settings → SSH and GPG keys → SSH keys" as an "Authentication key."
  • The associated email (frostcore.dev@proton.me) was verified on his GitHub account.
  • Locally, git log -1 --show-signature confirmed a "Good 'git' signature" with the correct ED25519 key fingerprint, matching the one registered on GitHub.

His Git configuration looked like this:

git config --global user.name "FrostCore"
git config --global user.email "frostcore.dev@proton.me"
git config --global gpg.format ssh
git config --global user.signingkey /home/jorge/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Despite this thorough setup, the GitHub UI displayed "Unverified" with the tooltip, "Upload your public signing SSH key to verify your signature." This created confusion, especially for those relying on clear commit status for github code review analytics and overall project health.

Distinction between SSH authentication and signing keys on GitHub.
Distinction between SSH authentication and signing keys on GitHub.

Unpacking the GitHub Distinction: Authentication vs. Signing Keys

The core of the problem, as quickly identified by community members nathan-probert and ben-24-0, lies in GitHub's specific handling of SSH keys. While a single SSH key pair can technically be used for both authentication (e.g., pushing code to repositories) and signing commits, GitHub requires them to be registered for their specific purpose on the platform.

Jorge had registered his key as an "Authentication key." This allows him to authenticate with GitHub, but it doesn't automatically enable it for commit signature verification. For SSH-signed commits to be recognized and marked "Verified," the public key must be explicitly registered as an "SSH signing key."

The Solution: Registering Your SSH Signing Key

The fix is straightforward:

  1. Navigate to your GitHub Settings → SSH and GPG keys.
  2. Click on "New SSH key."
  3. In the "Key type" dropdown, select "Signing key" instead of the default "Authentication key."
  4. Paste the exact same public key (e.g., ssh-ed25519 AAAAC3N... frostcore.dev@proton.me) that you use for authentication and for signing commits locally.
  5. Give it a descriptive title and click "Add SSH key."

Jorge-de-la-Flor confirmed that adding the same public key specifically as a "Signing key" immediately resolved the issue. All his previous SSH-signed commits, which were showing as "Unverified," instantly updated to "Verified."

Immediate Impact and Best Practices

This community insight underscores a vital detail for developers leveraging SSH for commit signing. The immediate update of past commits to "Verified" status upon registering the signing key is a testament to GitHub's robust verification system once the correct configuration is in place. For effective software development management, ensuring all commits are properly verified contributes significantly to auditability and trust within a team's codebase.

By understanding this distinction, developers can avoid unnecessary frustration and ensure their commit history accurately reflects the integrity of their contributions, bolstering confidence in their github code review analytics and overall development practices.