Comment on page
Git - Sign Commits with SSH
Sign your git commits using an SSH key stored in your Keeper Vault
Signing your git commits is important. It verifies authorship, ensures the integrity of committed content, prevents identity spoofing, and establishes non-repudiation. Using a cryptographic signature with your private key demonstrates a commitment to the authenticity and security of your contributions, building trust among collaborators and protecting the repository from potential tampering and malicious code.
This integration allows developers to sign git commits with an SSH key protected in your Keeper Vault (via Keeper Secrets Manager).
- Signs git commits using an SSH key stored in Keeper Vault.
- Removes the need for SSH keys on disk for secure DevOps workflows.
- Works on Windows, MacOS, and Linux.
In order to utilize this integration, you will need:
- Keeper Secrets Manager access (See the Quick Start Guide for more details)
- Secrets Manager add-on enabled for your Keeper account
- Membership in a Role with the Secrets Manager enforcement policy enabled
- Git installed with a minimum version of 2.34.0
- Login to the Keeper Web Vault or Desktop App
- Create a shared folder (e.g. "Git SSH Keys")
- Add a SSH Key record to the shared folder
In order to fetch the SSH key from your vault, this integration uses the zero-knowledge Keeper Secrets Manager.
It expects to find the Secrets Manager configuration file at
.config/keeper/ssh-sign.jsonin the user's home directory for all systems. If this configuration is not found, it will check
ssh-sign.jsonas a backup. The Secrets Manager application must have access to the shared folder in which your SSH key is stored.
After successfully configuring Secrets Manager, you can now configure git to sign your commits automatically. This can be done locally or globally, depending on your needs.
Four pieces of information are required in your config:
- 1.Tell git you want to sign all commits.
- 2.Tell git you want to use SSH signing over the default GPG signing.
- 4.Tell git the UID of the SSH key to be used to sign.
We can do this for the local Git repository with the following commands (add the
--globalflag to set these globally):
git config commit.gpgsign true
git config gpg.format ssh
git config gpg.ssh.program <path to this binary>
git config user.signingkey <SSH Key UID>
Your git config will now include these attributes:
gpgsign = true
format = ssh
signingKey = <SSH Key UID>
program = path/to/ssh-sign
For GitHub to verify the signature used to sign the commit, you will need to upload your SSH key's public key to your GitHub account. GitHub will then use this public key to verify the signature and display the
verifiedtag in the UI.
Important: Be sure to set the type of key to "signing key".
For GitLab to verify the signature used to sign the commit, you will need to upload your SSH key's public key to your GitLab account. GitLab will then use this public key to verify the signature and display the
verifiedtag in the UI.
Important: Be sure to set the type of key to "signing key" or "Authentication and signing".
Git is now configured to automatically sign all commits, regardless of whether you use the terminal or an IDE interface to interact with git. It also removes the need to use the
-Sflag for commit signing.
You can confirm your commit has been signed with
git show --pretty=rawin the terminal.
Once you have signed a commit and pushed it to GitHub or GitLab, you should see the verified tag next to your commit in the Git history automatically. No further work is needed.
If your repos are stored in your own datacenter, you can verify commits locally on the command line. In order to so this, you will need to create an
allowed_signersfile which is a record of authorized signing keys.
Typically, this file is saved either globally at
.ssh/allowed_signersor in the local repo at
.git/allowed_signers. The path to this file needs then to be added to your
git config gpg.ssh.allowedSignersFile path/to/file
Each line of your
allowed_signersfile should be a principal of an authorized signing key. The line should start with the email address associated with the public key, separated by a space. For example:
While it is correct syntax to have more than one email address associate with a single public key, it is not recommended or currently supported.
To verify your
# Verify all commits in the repo
git log --show-signature
# Verify the last commit in the repo
git log --show-signature -1