☰

Confirmar assinatura ok na estação de trabalho local, mas falha na mesma estação de trabalho por SSH?

tag-icon • tag-icon linux ssh git gnupg
Confirmar assinatura ok na estação de trabalho local, mas falha na mesma estação de trabalho por SSH?

Estou trabalhando em uma máquina Ubuntu 18.04.3 LTS x86_64 (totalmente corrigida). A máquina possui um desktop GNOME3. Às vezes eu sento na estação de trabalho e outras vezes faço SSH na estação de trabalho.

Ao sentar na estação de trabalho, a assinatura do commit do Git funciona. Eu uso git commit -S ... -m ...e as coisas funcionam como esperado. Recebo uma solicitação de interface do usuário para minha senha do GnuPG e o trabalho flui normalmente.

Quando trabalho remotamente na mesma estação de trabalho por SSH, tenho que renunciar à assinatura do commit porque:

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

Estou usando uma configuração "padrão" para SSH, Git e GnuPG. Não tenho conhecimento de nenhuma configuração especial para esta configuração. No entanto, o repositório está localizado na minha LAN local (e não no 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

Não há arquivo conf especializado do GnuPG em $HOME/.gnupg:

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

A pesquisa não está encontrando o problema. Estou ouvindo muito sobre falhas de assinatura do Git, mas não sobre resultados para esta situação específica.

Qual opção de configuração está faltando para que a assinatura funcione localmente e por SSH?

Aqui está pinentryna 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

E então:

$ 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

Responder1

Certifique-se de que seus arquivos de inicialização do shell (.bashrc ou .zshrc) definam a variável de ambiente $GPG_TTY:

export GPG_TTY=$(tty)

Existem várias camadas indiretas na maneira como o GnuPG mostra solicitações de senha. Ele não os mostra diretamente e nem mesmo inicia a interface do usuário "pinentry" diretamente - em vez disso, ele passa algumas variáveis ​​de ambiente relevantes para umagente gpgdaemon (que é compartilhado em todas as suas sessões) e, em seguida, o gpg-agent tenta iniciar o "pinentry" no TTY correto ou no display X11 correto.

Por alguma razão ainda inexplicável, quandogpgenvia as informações da sessão paraagente gpg, ele não se preocupa em procurar o TTY real por si só (ou mesmo passá-lo como descritor de arquivo); istosempreespera que a variável de ambiente $GPG_TTY esteja presente e contenha as informações.

Como alternativa, você pode evitar isso ativando a opção "loopback pinentry", onde as solicitações de senha do agente gpg voltam paragpgem vez de iniciar uma UI pinentry.

Para fazer isso, adicione a opção pinentry-mode loopbackem ~/.gnupg/gpg.conf.

(Em versões mais antigas (desatualizadas) do GnuPG, você também pode precisar da opção allow-loopback-pinentryem ~/.gnupg/gpg-agent.conf, e depois de adicioná-la você precisará atualizar com gpg-connect-agent reloadagent /bye. O GnuPG mais recente já permite o modo loopback por padrão.)

informação relacionada