SSH-Signatur-Verifizierer

What ssh-keygen -Y sign produces

Since OpenSSH 8.0, ssh-keygen -Y sign -f key -n namespace file signs arbitrary data with an SSH key and writes an armored block that starts with -----BEGIN SSH SIGNATURE-----. The format is SSHSIG, specified in PROTOCOL.sshsig in the OpenSSH source. Inside the base64 sits the SSHSIG magic, version 1, the signer's public key, a namespace, the name of the hash algorithm and the signature itself.

The key never signs the file directly. It signs a small structure: the magic, the namespace, a reserved field, the hash algorithm name and the hash of the file — SHA-512 by default, SHA-256 allowed, nothing else. The verifier rebuilds that structure from the file you give it and checks the signature with the key embedded in the block. RSA keys must sign with rsa-sha2-256 or rsa-sha2-512; an ssh-rsa (SHA-1) signature is rejected, as ssh-keygen rejects it. Ed25519, ECDSA P-256/P-384/P-521, the FIDO security-key types (sk-ssh-ed25519@openssh.com, sk-ecdsa-sha2-nistp256@openssh.com, whose user-presence flags and counter are shown) and SSH certificates are all read.

Why the namespace matters

The namespace says what the signature is for: file for files, git for commits and tags, email for messages, or a name of your own. Because it is inside the signed data, a signature made for one purpose cannot be replayed for another — a signed Git commit cannot pass as a signed release file. The verifier compares it with the namespace you expect (by default git for Git objects and file for everything else) and fails on a mismatch, exactly like ssh-keygen -Y verify -n.

Who may sign: allowed_signers

A valid signature only proves that some key signed. Which keys you trust, and for which identities, is the job of the allowed_signers file described in the ALLOWED SIGNERS section of ssh-keygen(1). Each line names principals (comma-separated patterns such as dev@example.com or *@example.org), optional options and a public key:

dev@example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA… laptop
ci@example.com namespaces="file",valid-before="20271231" ecdsa-sha2-nistp256 AAAA… release
*@example.com cert-authority ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA… company CA

The verifier applies the same rules as ssh-keygen: the identity you enter must match a principal pattern of a line whose key signed; namespaces= limits the purposes; valid-after and valid-before limit the time; and a cert-authority line trusts any SSH certificate that CA signed, provided the certificate is a user certificate, lists the identity among its principals and is valid at the signature time. Leave the identity empty to see every identity the file accepts for the key — what ssh-keygen -Y find-principals prints. If you only have the expected .pub key, paste it instead: it is trusted for any identity. Without either, the signature can be intact but the page says that nothing tells whose key it is — the situation behind Git's “gpg.ssh.allowedSignersFile needs to be configured”.

SSH-signed Git commits and tags

With git config gpg.format ssh, Git signs with ssh-keygen -Y sign -n git. A commit stores the armored signature in a gpgsig header (gpgsig-sha256 in a SHA-256 repository), and the signed bytes are the commit object without that header; a tag carries the signature at the end of its message. Paste the output of git cat-file commit HEAD or git cat-file tag v1.0.0: the verifier splits the object the way Git does, recomputes the object ID, and checks validity windows at the committer or tagger date, as git verify-commit does. A commit signed with OpenPGP is recognised and sent to the OpenPGP inspector; an X.509 (gpgsm or gitsign) signature is named as such. SSH or GPG for commits? The trade-offs are compared in SSH vs GPG commit signing.

The examples were made with OpenSSH 10 (ssh-keygen -Y sign) and Git 2.47 from this site's published test keys, and verified with ssh-keygen -Y verify and git verify-commit when they were generated. SSH keys and certificates themselves are decoded by the SSH key inspector; when to issue SSH certificates instead of listing keys is the subject of SSH certificates vs authorized_keys. For release artifacts signed without long-lived keys at all, see the Sigstore bundle verifier.