SSH Keys, Git Authentication & Commit Signing

In one line

SSH keys let you push and pull without typing a password every time, and commit signing lets Git (and platforms like GitHub) cryptographically prove a commit genuinely came from you.

0/4 · 0%

Think of it like this

SSH keys work like a lock that was custom-cut for one specific key you own (Linux's own SSH topic covered this exact idea) — the PUBLIC key can be shared freely with GitHub/GitLab, while the PRIVATE key stays on your machine and is never transmitted anywhere, yet the two together let the remote verify your identity with zero password ever sent over the network.

Key ideas

01
ssh-keygen -t ed25519 -C "you@example.com" generates a new key pair — the public half gets added to your GitHub/GitLab account settings, and from then on, cloning/pushing/pulling over an ssh:// (or git@github.com:...) URL authenticates automatically, with no username or password prompt at all.
02
HTTPS-based remote URLs (https://github.com/...) are the alternative to SSH — they typically authenticate via a PERSONAL ACCESS TOKEN (a long, revocable credential you generate on the platform) rather than your actual account password, since most platforms have stopped accepting plain passwords for Git operations entirely. Either SSH keys or a token works; most experienced developers default to SSH for its one-time setup and zero repeated prompts.
03
COMMIT SIGNING is a separate, additional layer: it cryptographically proves a specific commit genuinely came from you and hasn't been tampered with since — using either a GPG key or (increasingly common, and simpler to set up) the SAME SSH key you already use for authentication. A signed commit shows a 'Verified' badge on GitHub/GitLab; an unsigned one does not.
04
git config --global commit.gpgsign true (with a GPG key configured) or git config --global gpg.format ssh plus user.signingkey <path-to-your-ssh-key> (using SSH signing instead) makes EVERY future commit signed automatically, without needing to remember a flag each time — git commit -S signs just one commit manually if you'd rather opt in per-commit instead.
05
Signing matters most on projects where COMMIT AUTHENTICITY is a real security concern — verifying that a commit claiming to be from a specific maintainer genuinely is, rather than someone having configured git config user.email to impersonate them (which anyone can trivially do, since plain commit authorship is just a claim, not cryptographically verified, unless signing is used).

Code & diagrams

ssh-keys-and-signing.shmarkdown

The complete setup: authentication first, then signing using the same key.

# Generate a new SSH key pair (skip if you already have one from the Linux course)
ssh-keygen -t ed25519 -C "you@example.com"

# Copy the PUBLIC key — add this to GitHub/GitLab's SSH keys settings
cat ~/.ssh/id_ed25519.pub

# Test the connection (no password prompt if set up correctly)
ssh -T git@github.com
# Hi <username>! You've successfully authenticated...

# Switch a remote from HTTPS to SSH if it isn't already
git remote set-url origin git@github.com:your-username/your-repo.git

# --- Commit signing, using the SAME SSH key ---
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Every future commit is now signed automatically
echo "signed change" >> notes.txt
git add notes.txt
git commit -m "A cryptographically signed commit"

# Verify a commit's signature directly
git log --show-signature -1

Explain it without notes

Why does SSH-key authentication let you push and pull without a password prompt, while remaining secure?

What specific problem does commit signing solve that plain commit authorship (user.name / user.email) does not?

Practice

Generate an SSH key pair if you don't already have one, add the public key to your GitHub/GitLab account, and confirm ssh -T git@github.com authenticates successfully with no password prompt.

Configure commit signing using your SSH key, make a signed commit, and confirm with git log --show-signature that the signature is present and valid.

Trade-offs

↔
Commit signing adds genuine security value but also genuine friction (every contributor needs a properly configured signing key, and an unsigned commit from a legitimate contributor who hasn't set it up yet gets flagged as unverified) — most projects reasonably reserve REQUIRING signed commits for their most security-sensitive branches, rather than mandating it universally from day one.

Done when you can

I have SSH keys set up and can authenticate to GitHub/GitLab with no password prompt.
I understand what commit signing proves that plain commit authorship does not.
I can configure and verify signed commits using my own SSH key.