Im November letzten Jahres hatte ich euch erklärt, wie ihr unterschiedliche Git-Einstellungen für private und berufliche Projekte verwenden könnt. In einem Code-Schnipsel hatte ich dabei SSH-Keys zur Signierung von Commits verwendet. In der Vergangenheit hat man Commits in der Regel mit GPG-Keys signiert. Daher möchte ich euch heute zeigen, was ihr tun müsst, um stattdessen einen SSH-Key zur Signierung euer Commits zu verwenden.
Schritt 0: Erstellt ein SSH-Schlüsselpaar
Ihr habt vermutlich schon ein Schlüsselpaar. Wie sonst würdet ihr Repositories von einer Git-Hosting-Plattform klonen? Aber falls ihr noch kein SSH-Schlüsselpaar habt, führt diesen Befehl aus:
ssh-keygen -t ed25519 -C j.doe@example.com
Ich würde euch empfehlen, den ed25519 Verschlüsselungs-Algorithmus zu verwenden. Ihr könnt auch einen Kommentar setzen, ansonsten wird hier user@machine des Geräts verwendet, auf dem ihr den Schlüssel erstellt. Ich würde euch auch empfehlen eine „passphrase“ zu verwenden, aber diese ist nicht zwingend notwendig, um den Schlüssel für die Signierung von Commits zu verwenden.
Schritt 1: Aktualisiert eure Git-Konfiguration
Nachdem wir nun einen SSH-Key haben, können wir ihn zur Konfiguration hinzufügen. Wir können das mit dem folgenden Befehl tun:
git config --global user.signingkey ~/.ssh/id_ed25519
Da Git noch immer GPG-Keys als Standard verwendet, um Commits zu signieren, müssen wir einstellen, dass stattdessen SSH-Keys verwendet werden sollen. Das erreichen wir durch das Hinzufügen der folgenden Einstellung:
git config --global gpg.format ssh
Falls ihr bisher noch nie Commits signiert habt und dies in Zukunft immer tun wollt, dann führt noch diesen Befehl aus:
git config --global commit.gpgsign true
Lasst euch hier nicht durch den Namen gpgsign der Einstellung verwirren, es wird dennoch SSH verwenden, um eure Commits zu signieren.
Schritt 2: Festlegen der „allowed signers“ (optional)
Wenn ihr nun etwas commited und euch das Log inklusive der Signaturen anseht, dann erhaltet ihr folgenden Fehler:
git log --show-signature
error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
commit eccdf56431b052772b09027c5cea585b8e7eee32 (HEAD -> master)
No signature
Author: Jo Doe <j.doe@example.com>
Date: Sun Jan 29 19:07:52 2023 +0000
Das passiert, weil Git nicht wissen kann, ob die Public-Keys valide sind. Um das zu lösen, müssen wir noch eine andere Einstellung in die Git-Konfiguration hinzufügen:
git config --global gpg.ssh.allowedSignersFile ~/.git_allowed_signers
Diese Datei müssen wir jetzt noch erstellen, da wir sonst einen anderen Fehler bekommen. Ihr für pro Zeile jeweils einen Public-Key ein und schreibt in die erste „Zeile“ die dazugehörige E-Mail-Adresse, gefolgt vom Inhalt des Public-Keys. Die Datei könnte wie folgt aussehen:
# ~/.git_allowed_signers
j.doe@example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ818qdUM98GriqpTKhqMmwYAgeK3iiCg07Qgya5NwN/ j.doe@example.com
Wenn ihr euch jetzt das Git-Log erneut anseht, dann solltet ihr eine gültige Signatur sehen:
git log --show-signature
commit eccdf56431b052772b09027c5cea585b8e7eee32 (HEAD -> master)
Good "git" signature for j.doe@example.com with ED25519 key SHA256:/qGkPHs1/58u7jZgX95+hr5PNFs7gXswbkcRdfZuMWk
Author: Jo Doe <j.doe@example.com>
Date: Sun Jan 29 19:07:52 2023 +0000
Nach diesen ganzen Schritten sollte eure Git-Konfiguration (mindestens) wie folgt aussehen:
[user]
email = j.doe@example.com
name = Jo Doe
signingkey = ~/.ssh/id_ed25519
[commit]
gpgsign = true
[gpg]
format = ssh
[gpg "ssh"]
allowedSignersFile = ~/.git_allowed_signers
Schritt 3: Hinzufügen des Schlüssels zu Git-Hosting-Plattformen
Viele von euch werden wohl GitHub, GitLab oder andere Git-Hosting-Plattformen verwenden. Mindestens die beiden genannten Plattformen unterstützen auch SSH-Keys zur Signierung in ihrem UI.
Hinzufügen des Schlüssels zu GitHub
Navigiert zu „Settings | SSH and GPG keys„. Klickt dort auf den „New SSH key“ Button. Im Feld „Key type“ wählt ihr „Signing Key“ aus. Fügt dann euren Schlüssel ein und vergebt einen Titel:
Ihr könnt denselben Schlüssel verwenden, den ihr eventuell schon für einen „Authentication Key“ verwendet habt.
Hinzufügen des Schlüssels zu GitLab
Navigiert zu „Preferences (User Settings) | SSH Keys„. Hier könnt ihr den Schlüssel direkt in das Formular eintragen. Wählt dann entweder „Authentication & Signing“ oder nur „Signing“ im „Usage type“ Dropdown aus:
Standardmäßig hat ein Schlüssel bei GitLab ein Verfallsdatum, das ihr aber auch leer lassen könnt. Ihr könnt das Datum aber verlängern, indem ihr den Schlüssel entfernt und neu hinzufügt. Da SSH-Keys normalerweise kein Verfallsdatum haben (im Gegensatz zu GPG-Keys), könnt ihr die Einstellung ja mal testen.
Schritt 4: Prüfen, ob Commits signiert sind
Wir haben ja bereits auf der Kommandozeile im Git-Log überprüft, dass die Signierung funktioniert. In GitHub und GitLab könnt ihr die signierten Commits in fast allen Ansichten direkt neben den Commit-Hashes sehen. In der Commit-Liste auf GitHub könnte das wie folgt aussehen:
In der Commit-Liste von GitLab sieht es hingegen wie folgt aus:
Der „SSH key fingerprint“ ist hierbei der gleiche, den wir auch schon im Git-Log auf der Kommandozeile gesehen haben: /qGkPHs1/58u7jZgX95+hr5PNFs7gXswbkcRdfZuMWk.
Fazit
Für eine lange Zeit waren es GPG-Keys, die zum Signieren von Commits verwenden wurden. Aber da GPG im Setup und der Verwaltung sehr komplex sein kann, haben viele ihre Commits gar nicht erst signiert. Wenn ihr also GPG nicht ohnehin verwendet – um beispielsweise E-Mails zu signieren und/oder zu verschlüsseln – dann könnt ihr einfach SSH-Keys verwenden, um eure Commits zu signieren. Ihr könnt auch beides für verschiedene Projekte verwenden. In diesem Fall würde ich euch empfehlen, noch einmal meinen Beitrag zu unterschiedlichen Git-Konfigurationen zu lesen und die Einstellungen dann nicht in der globalen Konfigurationsdatei vorzunehmen, sondern in den eingebundenen Dateien.