Using a separate signing key per device

The instinct when setting up signing on a second machine is to copy the key from the first. It works immediately and it doubles the exposure: the key now lives in two places, and losing either device means revoking the key everywhere, including on the machine you still have. Per-device keys invert that. Each laptop, workstation, cloud development environment and hardware token generates its own key, which never leaves it. Losing a device costs exactly one revocation. The trust file grows by a line per device, and audits can tell which machine produced a commit. This page sets that up and keeps it manageable, as part of protecting and rotating signing keys.

When to use this approach

  • Engineers sign from more than one machine — a laptop and a workstation, or a laptop and a cloud development environment.
  • You use SSH signing, where adding another key is a line in a file rather than a ceremony.
  • You want a lost or decommissioned device to be a non-event for signing.
  • You would like audits to show which device made a commit, not just which person.
  • For GPG, the equivalent is one signing subkey per device under a shared primary, described in setting up GPG commit signing with subkeys.

Step 1 — Generate a key on each device, with a descriptive comment

Generate on the device itself. The comment is how you will recognise the key in a forge’s key list and in the trust file a year from now, so make it say what and where.

# Run on each device
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_signing \
  -C "signing:$(whoami)@$(hostname -s):$(date +%Y-%m)"
git config --global user.signingKey ~/.ssh/id_ed25519_signing.pub
git config --global gpg.format ssh
git config --global commit.gpgSign true
One shared key against one key per deviceA shared key copied to every device must be revoked everywhere when any device is lost. Per-device keys each live on one machine, so a loss revokes one line, and the signature reveals which device produced each commit.One key, copiedOne key per devicecopies of the secretone per deviceexactly one eachlaptop lostrevoke everywhererevoke one linewhich device signedunknownfrom the keysetup per new devicecopy a filegenerate + registerthe extra minute at setup buys a much smaller blast radius

Step 2 — Register each key with the forge under a clear title

Each key is registered as a signing key with a title that matches its comment. Forges allow many signing keys per account.

gh ssh-key add ~/.ssh/id_ed25519_signing.pub --type signing \
  --title "signing $(hostname -s) $(date +%Y-%m)"
gh api /user/ssh_signing_keys --jq '.[] | "\(.id)\t\(.title)\t\(.created_at[:10])"'
# Verification: a commit from this device shows as verified on the forge
git commit --allow-empty -m "device key test" && git push origin HEAD:refs/heads/device-key-test
gh api "repos/$OWNER/$REPO/commits/$(git rev-parse HEAD)" --jq '.commit.verification.verified'

Step 3 — Add every device key to the trust file

In the team’s allowed signers file, one person gets one line per device key, all with the same principal. If the file is generated from the forge’s API, this happens automatically because the generator fetches every registered signing key.

[email protected] namespaces="git" ssh-ed25519 AAAA...laptop  signing:alice@lt-0412:2026-10
[email protected] namespaces="git" ssh-ed25519 AAAA...ws      signing:alice@ws-0098:2026-03
[email protected] namespaces="git" [email protected] AAAA...token signing:alice@token:2026-01
One person, several device keysA single principal in the trust file maps to three keys: one on a laptop, one on a workstation and one on a hardware token. Verification succeeds with any of them, and each can be closed independently.[email protected] in the trust fileLaptop keylt-0412 · registered 2026-10Workstation keyws-0098 · registered 2026-03Hardware token keytouch required · 2026-01three keys, one identity — revoking one leaves the other two working

Step 4 — Identify which device signed a commit

Git can print the key fingerprint used for a signature. Matching that against registered keys tells you the device, which is useful when investigating a suspicious commit or confirming a lost laptop was not used after it went missing.

# Fingerprint of the key that signed each recent commit
git log -20 --format='%h %G? %GF %GS'

# Map fingerprints to device comments using the trust file
while read -r principal opts keytype key comment; do
  fp=$(printf '%s %s\n' "$keytype" "$key" | ssh-keygen -lf - | awk '{print $2}')
  echo "$fp $comment"
done < allowed_signers

Step 5 — Retire a device’s key when the device goes

When a device is lost, stolen or decommissioned, close its key in three places: the forge account, the trust file, and the device itself if you still have it.

# 1. Forge: remove the signing key by its ID
gh api -X DELETE "/user/ssh_signing_keys/$KEY_ID"

# 2. Trust file: close the window rather than deleting the line, so history still verifies
#    [email protected] namespaces="git",valid-before="20261002" ssh-ed25519 AAAA...laptop

# 3. Device, if recovered: destroy the key
shred -u ~/.ssh/id_ed25519_signing ~/.ssh/id_ed25519_signing.pub

⚠️ SAFETY WARNING: If the device was lost rather than retired, set valid-before to the time it went missing, not the time you noticed. Commits signed between those two moments may be forgeries and should be reviewed. Pick the earliest plausible time; a too-early date only forces a few legitimate commits to be re-signed, while a too-late one trusts a stolen key.

Retiring a lost laptop's signing keyThe forge registration is removed so new pushes show unverified. The trust file line gets a valid-before date set to when the device went missing. Commits signed after that date are reviewed, and the remaining device keys carry on unaffected.Device lostnote the timeForgedelete signing keyTrust filevalid-before setReviewcommits after that timeCarry onother devices unaffectedwith per-device keys, a lost laptop is a ticket, not an incident

Validation checklist

Frequently Asked Questions

Does this make the trust file unmanageable?

It roughly doubles or triples its length, which is still small — a hundred-person team with three devices each has three hundred lines. Generating the file from the forge API keeps it accurate without anyone editing it by hand.

What about cloud development environments that are recreated often?

Either generate a key per environment and register it automatically on creation, or — usually better — have the environment forward signing requests to the agent on the engineer’s laptop. Forwarding means no key ever lives in the ephemeral environment.

Is a hardware token one device or many?

One. A token’s key is tied to that token. If you carry two tokens, each has its own key and its own trust-file line.