Commits mit SSH-Keys signieren statt GPG: Einrichtung und Praxis

1. Warum Commits überhaupt signieren

Das Autoren-Feld eines Git-Commits besteht aus reinem, unbeglaubigtem Text, Name und E-Mail-Adresse lassen sich mit git commit --author beliebig setzen, ohne dass irgendein Nachweis erbracht werden muss, dass die angegebene Person den Commit tatsächlich erstellt hat. Eine kryptografische Signatur schließt genau diese Lücke, indem sie belegt, dass ein Commit mit dem privaten Schlüssel einer bestimmten, überprüfbaren Identität erzeugt wurde.

Gerade in Projekten mit mehreren Mitwirkenden oder bei sicherheitsrelevantem Code schafft eine verifizierte Signatur zusätzliches Vertrauen bei Code-Reviews und liefert im Ernstfall einen belastbaren Nachweis, welche konkrete Person hinter einem bestimmten Commit steht. Bei einem kompromittierten Zugang, etwa wenn ein gestohlenes Zugangstoken für Push-Operationen missbraucht wird, hilft eine konsequente Signaturpflicht zusätzlich dabei, gefälschte Commits von echten zuverlässig zu unterscheiden, da ein Angreifer ohne den passenden privaten Schlüssel keine gültige Signatur erzeugen kann.

2. Warum GPG-Signierung in der Praxis oft ausgebremst wird

GPG bringt für die Commit-Signierung eine vollständig eigenständige Schlüsselverwaltung mit, inklusive Web-of-Trust-Konzept, separatem gpg-agent-Prozess und eigenem Schlüsselformat, das mit den ohnehin schon vorhandenen SSH-Schlüsseln nichts zu tun hat. Für viele Entwicklerinnen und Entwickler bedeutet das einen zusätzlichen Werkzeugstapel, der ausschließlich für diesen einen Zweck installiert und gepflegt werden muss.

In der Praxis führt genau dieser zusätzliche Aufwand häufig dazu, dass GPG-Signierung trotz vorhandener Richtlinie schlicht nicht konsequent genutzt wird, weil der gpg-agent nach einem Neustart erneut nach der Passphrase fragt, die Schlüsselerzeugung ungewohnt komplex wirkt und die Fehlermeldungen bei falscher Konfiguration selten selbsterklärend sind. Besonders auf neu eingerichteten Entwicklungsrechnern oder in containerisierten Build-Umgebungen scheitert die GPG-Einrichtung häufig schon an fehlenden Zufallsquellen für die Schlüsselerzeugung oder an einem gpg-agent, der ohne grafische Oberfläche gar nicht erst nach der Passphrase fragen kann.

3. SSH-Signaturen als Alternative seit Git 2.34

Seit Git 2.34 unterstützt Git mit gpg.format ssh ein zweites, alternatives Signaturformat, das intern auf die SSH-Signaturfunktion von OpenSSH zurückgreift, konkret auf ssh-keygen -Y sign und ssh-keygen -Y verify. Dadurch lässt sich exakt derselbe SSH-Schlüssel, der ohnehin schon für die Authentifizierung gegenüber dem Git-Server genutzt wird, unmittelbar auch zum Signieren von Commits verwenden.

Das reduziert die Einstiegshürde erheblich, da kein zusätzliches Schlüsselpaar erzeugt und keine separate Software installiert werden muss, wer bereits per SSH pusht, hat in aller Regel schon alles, was für die Signierung nötig ist.

4. Git für SSH-Signierung konfigurieren

Die Umstellung erfolgt über drei Konfigurationswerte: gpg.format wird auf ssh gesetzt, user.signingkey verweist auf den Pfad des öffentlichen SSH-Schlüssels, und commit.gpgsign aktiviert die automatische Signierung für jeden künftigen Commit, ohne dass die Option -S jedes Mal manuell angegeben werden muss. Alle drei Werte lassen sich sowohl global für alle Repositories eines Rechners als auch gezielt für ein einzelnes Projekt setzen, was sich anbietet, wenn nur bestimmte Repositories einer Signierungspflicht unterliegen sollen.

Wird zusätzlich tag.gpgsign gesetzt, gilt dieselbe automatische Signierung auch für annotierte Tags, was sich besonders für Release-Tags empfiehlt, deren Herkunft ebenfalls überprüfbar sein sollte.

# Git auf SSH-basierte Signierung umstellen
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

5. Die allowed_signers Datei für lokale Verifikation

Damit Git eine SSH-Signatur lokal auch tatsächlich überprüfen kann, benötigt es eine Zuordnung zwischen E-Mail-Adresse und öffentlichem Schlüssel in einer sogenannten allowed_signers Datei, deren Pfad über gpg.ssh.allowedSignersFile hinterlegt wird. Jede Zeile in dieser Datei koppelt eine E-Mail-Adresse an genau einen öffentlichen Schlüssel im bekannten OpenSSH-Format.

Ohne diese Datei kann Git zwar weiterhin signieren, aber weder git log --show-signature noch git verify-commit liefern dann ein sinnvolles Ergebnis, da schlicht die Referenzinformation fehlt, welcher öffentliche Schlüssel zu welcher Identität gehört. Für ein Team empfiehlt es sich, diese Datei nicht nur lokal auf jedem einzelnen Rechner zu pflegen, sondern als zentrale, versionierte Referenz im Projekt selbst abzulegen, damit neue Mitglieder nicht erst mühsam jeden öffentlichen Schlüssel einzeln von Hand zusammensuchen müssen.

# Pfad zur allowed_signers Datei hinterlegen
git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers

# Inhalt der Datei: eine Zeile pro Identität
# max@mironsoft.de ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIxxxxx...

6. Commits signieren und die Signatur prüfen

Ist commit.gpgsign aktiviert, wird jeder neue Commit ohne weiteres Zutun automatisch signiert. Ohne diese globale Einstellung lässt sich ein einzelner Commit auch gezielt mit der Option -S signieren, was sich für einen schrittweisen Einstieg anbietet, bevor die automatische Signierung für alle künftigen Commits aktiviert wird.

Zur Überprüfung liefert git log --show-signature direkt in der Log-Ausgabe an, ob und mit welchem Schlüssel ein Commit signiert wurde, während git verify-commit gezielt für einen einzelnen Commit-Hash denselben Nachweis erbringt und sich damit gut in ein automatisiertes Prüfskript einbauen lässt.

# Einzelnen Commit gezielt signieren
git commit -S -m "Feature: Preisberechnung überarbeitet"

# Signatur eines bestimmten Commits prüfen
git verify-commit HEAD

7. Unterstützung bei GitHub und GitLab

GitHub akzeptiert SSH-Signing-Keys als eigenen Schlüsseltyp, der getrennt vom regulären Authentifizierungsschlüssel in den Kontoeinstellungen hinterlegt wird, auch wenn beide technisch derselbe Schlüssel sein können. Ein erfolgreich verifizierter Commit erhält dort dasselbe grüne Verified-Abzeichen, das zuvor ausschließlich GPG-signierten Commits vorbehalten war.

GitLab unterstützt SSH-Signaturen ebenfalls, verwaltet die zugehörigen öffentlichen Schlüssel in den Benutzereinstellungen und zeigt verifizierte Commits in der Web-Oberfläche mit einem entsprechenden Hinweis an, sodass sich die Verifikation nicht nur lokal, sondern auch im Team sichtbar nachvollziehen lässt.

8. SSH- und GPG-Signierung im direkten Vergleich

Der größte praktische Unterschied liegt im Verwaltungsaufwand: SSH-Signierung nutzt die ohnehin vorhandene Schlüsselinfrastruktur, während GPG eine komplett eigenständige, parallele Verwaltung mitbringt. Beim Widerruf eines kompromittierten Schlüssels bietet GPG mit seinem Revocation-Certificate-Konzept allerdings einen etwas ausgereifteren, dedizierten Mechanismus als die SSH-Welt.

Ein klarer Vorteil von SSH-Signierung zeigt sich beim Einsatz von Hardware-Sicherheitsschlüsseln: FIDO2-Token wie ein YubiKey lassen sich über den ssh-agent direkt für die Signierung nutzen, ohne dass zusätzlich ein separates GPG-Smartcard-Setup eingerichtet werden müsste. Wer bereits einen Hardware-Token für die SSH-Authentifizierung im Einsatz hat, profitiert dadurch doppelt, da derselbe physische Schlüssel ohne zusätzliche Anschaffung auch die Signierfunktion übernimmt und der private Schlüssel dabei zu keinem Zeitpunkt den Hardware-Token verlässt.

9. Signierung im Team verbindlich einführen

Für eine verbindliche Einführung im Team empfiehlt sich, commit.gpgsign und gpg.format ssh über eine zentrale, dokumentierte Onboarding-Anleitung zu verteilen, statt sich auf die individuelle Konfiguration jeder einzelnen Entwicklerin und jedes einzelnen Entwicklers zu verlassen. Auf Server-Seite lässt sich die Pflicht zur Signierung zusätzlich über Push-Regeln oder Einstellungen für geschützte Branches technisch erzwingen.

Die allowed_signers Datei selbst kann sinnvollerweise sogar direkt im Projekt-Repository gepflegt und über einen relativen include-Pfad in der lokalen Git-Konfiguration eingebunden werden, sodass neue Team-Mitglieder automatisch die aktuelle, zentral gepflegte Liste erhalten, sobald sie das Repository klonen, ohne dass ein zusätzlicher, separater Verteilungsschritt für die eigentliche Schlüsselliste nötig wird.

10. Zusammenfassung

11. FAQ: SSH Commit-Signierung