📣 Prerequisites • 💡 Motivation • 🎒 Exercises • 🚀 Beyond • 📚 Resources
Note Everything here should be taken with a grain of 🧂 as purely an opinion of the author.
This workshop is aimed at getting participants started with SSH code signing. One of the topics not covered is managing trust for hundreds or thousands of SSH keys across an enterprise as the steps in "Exercise: Setup workstation" had participants setup to only trust their own SSH key:
Create file containing SSH public key for verifying signers
awk '{ print $3 " " $1 " " $2 }' ~/.ssh/id_ed25519.pub >> ~/.ssh/allowed_signers
Unlike GPG keyservers, which can be used to distribute GPG keys uploaded by individuals, SSH keys are not distributed the same way. As Git's SSH code signing is built on top of ssh-keygen allowed signers, a different approach to establishing trust is needed: certificate authorities or CAs.
Using the cert-authority option, the principal field of the allowed signers line can take a wildcard entry to trust a larger domain of email addresses using SSH keys signed by the CA:
# A certificate authority, trusted for all principals in a domain.
*@example.com cert-authority ssh-ed25519 AAAB4...
For enterprises with open source programs, this becomes more difficult, demonstrating opportunity for source control vendors.
GPG has been designed so individuals can revoke keys from keyservers, immediately making it untrusted by anyone else using the keyserver. SSH keys do not have a similar process of revoking untrusted keys or broadcasting information about untrusted keys.
Next: 🚀 Beyond