git commit bricht mit „gpg failed to sign the data“ ab? Meist fehlt der passende Schlüssel, oder GPG kann im Terminal nicht nach der Passphrase fragen.
Aufwand:
ca. 25 Min.
Das Symptom
Ein git commit lässt sich nicht abschließen und endet mit error: gpg failed to sign the data und fatal: failed to write commit object. Der Commit wird nicht
erstellt. Ohne Signatur — oder auf einem anderen Rechner — funktioniert dasselbe
Committen problemlos.
Die „Layer 8“-Wahrheit
Signierte Commits sind eine gute Sache: Sie belegen kryptografisch, dass ein Commit
wirklich von dir stammt. Ist Git aber angewiesen zu signieren und kann es nicht,
verweigert es lieber den ganzen Commit, als einen unsignierten anzulegen. Der Fehler
ist also die Folge einer Sicherheitseinstellung, die ins Leere läuft. Die Ursache
liegt fast immer an einer von zwei Stellen: Der Schlüssel, mit dem signiert werden
soll, passt nicht zu einem vorhandenen geheimen Schlüssel — oder GPG bekommt im
Terminal keine Gelegenheit, nach der Passphrase zu fragen.
Gerade der zweite Fall ist tückisch, weil er scheinbar willkürlich auftritt: In einer
grafischen Sitzung öffnet sich ein Abfragefenster, in einer reinen Terminal- oder
SSH-Sitzung nicht — und ohne Passphrase keine Signatur. Das Setzen der richtigen
Terminal-Variable gibt GPG diesen Weg zurück. Wer beide Seiten prüft — existiert der
Schlüssel, und kann GPG überhaupt signieren — findet die Ursache schnell, statt das
Signieren entnervt ganz abzuschalten und damit den Sinn der Übung aufzugeben.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Ursache eingrenzen
Git ist so eingestellt, dass es Commits signiert, kann aber nicht signieren. Die häufigsten Gründe: Es ist kein passender Schlüssel hinterlegt, der konfigurierte Schlüssel existiert nicht mehr, oder GPG kann im Terminal nicht nach der Passphrase fragen. Zuerst prüfen, welche Schlüssel überhaupt vorhanden sind:
gpg --list-secret-keys --keyid-format=long
2.
Den richtigen Schlüssel hinterlegen
Git die zu verwendende Schlüssel-Kennung mitteilen, die zu einem tatsächlich vorhandenen geheimen Schlüssel passt. Stimmt der eingetragene Schlüssel nicht mit einem existierenden überein, scheitert jede Signatur:
GPG braucht einen Weg, nach der Passphrase zu fragen (einen Pinentry). In einer reinen Terminal-Sitzung ohne grafische Oberfläche scheitert das oft. Die Umgebungsvariable für das Steuerterminal setzen, damit GPG im Terminal fragen kann:
export GPG_TTY=$(tty)
4.
Die Signatur direkt testen
Unabhängig von Git prüfen, ob GPG überhaupt signieren kann. Klappt das nicht, liegt das Problem bei GPG selbst — abgelaufener Schlüssel, blockierter Agent —, nicht bei Git:
echo test | gpg --clearsign
5.
Abgelaufene Schlüssel und Agent prüfen
Ein abgelaufener oder widerrufener Schlüssel kann nicht mehr signieren; seine Gültigkeit prüfen und ihn gegebenenfalls verlängern. Hängt der GPG-Agent, hilft ein Neustart des Agents, damit die Passphrase-Abfrage wieder funktioniert.
Häufige Fragen (FAQ)
?Der Commit scheitert mit einem GPG-Fehler, obwohl der Schlüssel existiert. Warum?
Meist, weil Git und GPG von verschiedenen Schlüsseln ausgehen. Git nimmt den in user.signingkey hinterlegten – ist dort ein alter oder gar keiner eingetragen, greift GPG ins Leere. Ein häufiger zweiter Grund: Der Schlüssel ist abgelaufen. Beides zeigt gpg --list-secret-keys in Sekunden.
?Es kommt gar keine Passphrase-Abfrage, es scheitert einfach. Was fehlt?
Der Umgebungsvariablen GPG_TTY fehlt die Zuordnung zum Terminal. Ohne sie weiß der GPG-Agent nicht, wo er nach der Passphrase fragen soll, und bricht wortlos ab. Ein export GPG_TTY=$(tty) in der Shell-Konfiguration löst das dauerhaft.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Git meldet „detached HEAD“? Du stehst nicht auf einem Branch, sondern direkt auf einem Commit — Änderungen hier gehen ohne Gegenmaßnahme leicht verloren.
SWAnfängerfehlerYour local changes would be overwritten
git stoppt mit 'Your local changes would be overwritten by merge/checkout'? So rettest du deine Änderungen per commit oder stash, statt sie zu verlieren.
SSH verweigert den Schlüssel, weil die Rechte zu offen seien? Ein privater Schlüssel darf nur dir gehören — mit einem chmod ist es in Sekunden behoben.
Der Diff markiert jede Zeile als geändert, obwohl nur ein Wort angepasst wurde? Zeilenenden. Windows und Unix streiten sich um ein unsichtbares Zeichen.