☰

Commit-Signierung auf lokaler Arbeitsstation erfolgreich, schlägt aber auf derselben Arbeitsstation über SSH fehl?

tag-icon • tag-icon linux ssh git gnupg
Commit-Signierung auf lokaler Arbeitsstation erfolgreich, schlägt aber auf derselben Arbeitsstation über SSH fehl?

Ich arbeite an einer Ubuntu 18.04.3 LTS x86_64-Maschine (vollständig gepatcht). Die Maschine hat einen GNOME3-Desktop. Manchmal sitze ich an der Arbeitsstation und manchmal melde ich mich per SSH bei der Arbeitsstation an.

Wenn ich an der Arbeitsstation sitze, funktioniert die Signierung von Git-Commits. Ich verwende git commit -S ... -m ...und alles funktioniert wie erwartet. Ich erhalte eine UI-Eingabeaufforderung für mein GnuPG-Passwort und der Arbeitsablauf läuft wie gewohnt ab.

Wenn ich remote über SSH an derselben Workstation arbeite, muss ich auf die Commit-Signierung verzichten, weil:

$ git commit -S log.h -m "Remove unneeded header"
error: gpg failed to sign the data
fatal: failed to write commit object

Ich verwende eine „Standard“-Konfiguration für SSH, Git und GnuPG. Mir sind keine speziellen Konfigurationen für dieses Setup bekannt. Das Repo befindet sich jedoch in meinem lokalen LAN (und nicht auf GitHub, GitLab usw.):

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = ssh://git@callmaster:/var/callboot-src
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

Es gibt keine spezielle GnuPG-Konfigurationsdatei in $HOME/.gnupg:

$ ls -A ~/.gnupg/
3F537D88ADBC1677-private-key.asc  pubring.kbx
private-keys-v1.d                 trustdb.gpg

Die Suche findet das Problem nicht. Ich bekomme viele Informationen zu Git-Signaturfehlern, aber keine Ergebnisse für diese spezielle Situation.

Welche Konfigurationsoption fehlt mir, damit die Signierung lokal und über SSH funktioniert?

Hier steht pinentryauf der Maschine:

$ ls -Al /usr/bin/pinentry-*
-rwxr-xr-x 1 root root 63992 Feb  5  2018 /usr/bin/pinentry-curses
-rwxr-xr-x 1 root root 72184 Feb  5  2018 /usr/bin/pinentry-gnome3
lrwxrwxrwx 1 root root    30 Sep  2 19:14 /usr/bin/pinentry-x11 -> /etc/alternatives/pinentry-x11

Und dann:

$ ls -Al /etc/alternatives/pinentry-*
lrwxrwxrwx 1 root root 24 Sep  2 19:14 /etc/alternatives/pinentry-x11 -> /usr/bin/pinentry-gnome3
lrwxrwxrwx 1 root root 40 Sep  2 19:14 /etc/alternatives/pinentry-x11.1.gz -> /usr/share/man/man1/pinentry-gnome3.1.gz

Antwort1

Stellen Sie sicher, dass Ihre Shell-Startdateien (.bashrc oder .zshrc) die Umgebungsvariable $GPG_TTY festlegen:

export GPG_TTY=$(tty)

Es gibt mehrere Ebenen der Indirektion in der Art und Weise, wie GnuPG Passwortabfragen anzeigt. Es zeigt sie nicht direkt an und startet nicht einmal die Benutzeroberfläche „Pinentry“ direkt – stattdessen übergibt es einige relevante Umgebungsvariablen an einenGPG-AgentDaemon (der für alle Ihre Sitzungen gemeinsam genutzt wird) und dann versucht der GPG-Agent, „Pinentry“ auf dem richtigen TTY oder dem richtigen X11-Display zu starten.

Aus einem noch ungeklärten Grund, alsgpgsendet die Sitzungsinformationen anGPG-Agent, es macht sich nicht die Mühe, das echte TTY selbst zu suchen (oder es sogar als Dateideskriptor zu übergeben); esstetserwartet, dass die Umgebungsvariable $GPG_TTY vorhanden ist und die Informationen enthält.

Alternativ können Sie dies vermeiden, indem Sie die Option „Loopback Pinentry“ aktivieren, bei der die Passphrase-Anfragen des GPG-Agenten zurück zugpganstatt eine Pinentry-Benutzeroberfläche zu starten.

Fügen Sie dazu die Option pinentry-mode loopbackzu ~/.gnupg/gpg.conf hinzu.

(In älteren (veralteten) GnuPG-Versionen benötigen Sie möglicherweise auch die Option allow-loopback-pinentryin ~/.gnupg/gpg-agent.conf, und nach dem Hinzufügen müssen Sie mit aktualisieren gpg-connect-agent reloadagent /bye. Das neueste GnuPG ermöglicht den Loopback-Modus bereits standardmäßig.)

verwandte Informationen