☰

¿Se confirma la firma en la estación de trabajo local, pero falla en la misma estación de trabajo a través de SSH?

tag-icon • tag-icon linux ssh git gnupg
¿Se confirma la firma en la estación de trabajo local, pero falla en la misma estación de trabajo a través de SSH?

Estoy trabajando en una máquina Ubuntu 18.04.3 LTS x86_64 (completamente parcheada). La máquina tiene un escritorio GNOME3. A veces me siento en la estación de trabajo y otras veces entro por SSH en la estación de trabajo.

Cuando está sentado en la estación de trabajo, la firma de confirmación de Git funciona. Lo uso git commit -S ... -m ...y todo funciona como se esperaba. Recibo un mensaje en la interfaz de usuario para mi contraseña de GnuPG y el trabajo fluye como de costumbre.

Cuando trabajo de forma remota en la misma estación de trabajo a través de SSH, tengo que renunciar a la firma de confirmación porque:

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

Estoy usando una configuración "estándar" para SSH, Git y GnuPG. No conozco ninguna configuración especial para esta configuración. Sin embargo, el repositorio se encuentra en mi LAN local (y no en GitHub, GitLab, etc.):

$ 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

No hay ningún archivo de configuración GnuPG especializado en $HOME/.gnupg:

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

La búsqueda no encuentra el problema. Recibo mucho sobre fallas en la firma de Git, pero no resultados para esta situación en particular.

¿Qué opción de configuración me falta para que la firma funcione localmente y a través de SSH?

Aquí está pinentryen la máquina:

$ 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

Y luego:

$ 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

Respuesta1

Asegúrese de que sus archivos de inicio de shell (.bashrc o .zshrc) establezcan la variable de entorno $GPG_TTY:

export GPG_TTY=$(tty)

Hay varias capas de indirección en la forma en que GnuPG muestra las solicitudes de contraseña. No los muestra directamente y ni siquiera inicia la interfaz de usuario "pinentry" directamente; en lugar de eso, pasa algunas variables de entorno relevantes a unagente-gpgdaemon (que se comparte en todas sus sesiones) y luego gpg-agent intenta iniciar "pinentry" en el TTY correcto o en la pantalla X11 correcta.

Por alguna razón aún inexplicable, cuandogpgenvía la información de la sesión aagente-gpg, no se molesta en buscar el TTY real por sí solo (o incluso pasarlo como descriptor de archivo); élsiempreespera que la variable de entorno $GPG_TTY esté presente y contenga la información.

Como alternativa, puede evitar esto habilitando la opción "pinentry de bucle invertido", donde las solicitudes de contraseña de gpg-agent viajan de regreso agpgen lugar de iniciar una interfaz de usuario pinentry.

Para hacerlo, agregue la opción pinentry-mode loopbacka ~/.gnupg/gpg.conf.

(En versiones anteriores (obsoletas) de GnuPG, es posible que también necesites la opción allow-loopback-pinentryen ~/.gnupg/gpg-agent.conf, y después de agregarla necesitarás actualizar con gpg-connect-agent reloadagent /bye. La última versión de GnuPG ya permite el modo loopback de forma predeterminada).

información relacionada