Início / unix / Perguntas / 772267
Accepted
lyndhurst
Asked: 2024-03-13 23:08:12 +0800 CST

Recupere chaves secretas gpg com backup incorreto

  • 772

Acabei de restaurar meus dados de um repositório de backup borg após uma falha no computador.

Minha ~/.gnupgpasta parece boa, as chaves privadas estão lá e as permissões parecem corretas. Normalmente Borg faz um bom trabalho nisso. Quando eu acesso catos arquivos de chaves privadas, não há sinal de corrupção de dados.

No entanto, não posso listar ou usar as chaves privadas. Só consigo interagir com uma chave pública que foi importada pacmandurante o processo de instalação.

Me deparei com alguns posts com problemas semelhantes de chaves privadas não reconhecidas após serem copiadas de uma máquina para outra, e geralmente o problema é resolvido seguindo recomendações de repetir a transferência usando gpg —export-keye depois importá-las com o comando oposto.

Infelizmente não tenho esse luxo, pois minha máquina antiga travou e não pode ser recuperada. Eu estava ciente da importação e exportação de chaves, mas sempre presumi que era apenas um procedimento seguro mover chaves.

Então eu tenho duas perguntas:

Preciso revisar meus scripts de backup e usar o comando de exportação para minhas chaves secretas gpg?

Mesmo assim, posso recuperar minhas chaves secretas?

======= Editar ======

Encontrei uma postagem no fórum do arch com um usuário tendo exatamente o mesmo problema que eu, então consegui mais pistas para seguir.

O que eu tentei até agora:

gpg --version
> gpg (GnuPG) 2.4.5

ps aux | grep gpg-a
>  /usr/bin/gpg-agent --supervised

#About ownership: 
chown -R $USER:$USER .gnupg

# Checking UID/GID with show a result of `1000` both on filesystem # # and backup archive.
ls -vn .gnupg/private-keys-v1.d 

gpg --export-secret-keys
> gpg: WARNING: nothing exported

gpg -v --list-secret-keys
> gpg: enabled compatibility flags:
> gpg: using pgp trust model

# Most relevant results of:
strace -f -o /tmp/gpg.strace gpg --list-secret-keys
cat /tmp/gpg.strace
> 76220 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> 76220 access("/home/$USER/.gnupg/secring.gpg", F_OK) = -1 ENOENT (No such file or directory)

# Listing public keys
gpg --list-keys
> Returns one public key imported by pacman during install

gpg -K
> Returns nothing

ls -ln .gnupg/
.rw-r-----   12 1000 13 Mar 10:45 common.conf
drwx------    - 1000  6 Sep  2023 crls.d
.rw------- 2.0k 1000 13 Sep  2023 gpg-agent.conf
.rw-------  703 1000  5 Mar 18:48 gpg.conf
drwx------    - 1000 30 Aug  2023 private-keys-v1.d
drwxr-x---    - 1000 14 Mar 19:27 public-keys.d
.rw-r--r--    0 1000 24 Aug  2023 pubring.gpg
.rw-r--r-- 7.7k 1000  5 Mar 12:13 pubring.kbx
.rw-r--r-- 7.0k 1000  7 Sep  2023 pubring.kbx~
.rw-------  600 1000  8 Mar 07:20 random_seed
.rw-r-----  676 1000 30 Aug  2023 sshcontrol
.rw------- 1.6k 1000  2 Sep  2023 trustdb.gpg
backup

1 respostas

  1. Best Answer

    Estou tentando instalar o garuda kde no momento e descobri que ele vem com algumas configurações gpg padrão que ainda não descobri completamente.

    De qualquer forma, acontece que algum processo recria constantemente uma .gnupgpasta básica. Não parece que a culpa seja do agente gpg, já que consegui desabilitar todos os serviços systemd relacionados ao gpg (principalmente gpg-agent.servicee gpg-agent.socket) como usuário e root e depois killall gpg-agent.

    O que estava acontecendo é que eu nunca restauraria minha própria pasta gpg a partir de backups, mas mesclá-la com uma criada automaticamente e por alguns motivos não funcionaria.

    Finalmente, apenas para ter certeza de que encontrei o culpado, consegui rm -rfa pasta e restaurá-la do backup usando um script para que qualquer processo que estivesse recriando-a não tivesse tempo para fazê-lo.

    Tem funcionado bem desde então.

    • 0

relate perguntas