Yes. Git supports SSH keys as a signing format. Set the signing format to ssh, point git at your key, and sign tags as usual. To verify, you give git an allowed signers file listing the public keys you trust. Check your git version supports it first.
Why people choose SSH signing
Many maintainers already have an SSH key and an agent running. Reusing it avoids installing and learning a second tool. The git-config documentation lists ssh as a possible value for the signing format, next to the default openpgp and x509.
Steps to sign
- Choose the format.
git config gpg.format ssh
git config user.signingkey ~/.ssh/id_ed25519.pub
- Create the tag.
git tag -s v2.4.0 -m "Release 2.4.0"
The git-tag manual says the signing backend depends on the gpg.format setting, and that for SSH the default key may be a specific key file or an agent identity.
Steps to verify
Verification needs to know which keys you trust. The git-config documentation describes an allowed signers file: lines of principals followed by an SSH public key, in the format described in the ssh-keygen manual.
git config gpg.ssh.allowedSignersFile ~/.config/git/allowed_signers
git tag -v v2.4.0
The documentation explains that the principal only identifies the key, and that SSH has no concept of trust levels like GPG does. So the file is your trust decision. Only list keys you have confirmed.
Revoking and rotating
git-config also describes a revocation file, either an SSH key revocation list or a plain list of revoked public keys. A key found there is treated as never trusted and its signatures show as invalid. That gives you a way to cut off a lost key on the verifying side.
SSH or GPG: a short comparison
| Question | SSH signing | GPG signing |
|---|---|---|
| Tooling you probably already have | Yes, if you use SSH | Maybe not |
| Built in trust levels | No | Yes, a web of trust model |
| Who must you tell your key to | Every verifier, through their allowed signers file | Via a keyserver or published key |
| Works with git tag signing | Yes | Yes |
Neither is more secure by name alone. What matters is how you protect the private key and how verifiers learn which public key to trust.
Practical advice
- Keep a dedicated signing key for releases if several people tag.
- Publish the public key and fingerprint in more than one place.
- Document the verification steps for users. See how to write a verify page for your releases.
Hosting site display
Some hosting services show a verified badge for signed commits and tags if the public key is registered with them. That badge depends on the host's own rules, so do not treat its absence or presence as the whole story. Your own verification, with your own allowed signers file, is the check you control.
Quick check
Does an SSH signed tag show as verified everywhere?
Not automatically. Each verifier needs the public key in their own allowed signers file or equivalent, and hosting sites have their own rules. Check the documentation of each tool you rely on.
Should I sign commits too?
It helps accountability, but a signed release tag is the minimum for a release. Decide commit signing as a team.
Sources
Last reviewed: 19 October 2026.
