Início / user-269105

lopass's questions

Martin Hope
lopass
Asked: 2023-06-13 19:50:29 +0800 CST
  • 6

Usei a configuração yubikey do Dr. Duh há cerca de 20 dias sem problemas. Eu o examinei novamente ontem à noite em um Mac M1 com Brew e, quando criamos a chave de autenticação expirada, a lista de chaves mostra [AR] para a chave onde normalmente mostraria apenas [A] para autenticação. Eu consultei as man pages em gnu.org e enquanto posso ver os outros códigos (E,S,A) - não vejo nenhuma definição para R. O que é R?

Isso é algo parecido com o que vejo na etapa da lista (copiado do guia do Dr. Duh e alterado para adicionar o R):

$ gpg -K
/tmp.FLZC0xcM/pubring.kbx
-------------------------------------------------------------------------
sec   rsa4096/0xFF3E7D88647EBCDB 2017-10-09 [C]
      Key fingerprint = 011C E16B D45B 27A5 5BA8  776D FF3E 7D88 647E BCDB
uid                            Dr Duh <[email protected]>
ssb   rsa4096/0xBECFA3C1AE191D15 2017-10-09 [S] [expires: 2018-10-09]
ssb   rsa4096/0x5912A795E90DD2CF 2017-10-09 [E] [expires: 2018-10-09]
ssb   rsa4096/0x3F29127E79649A3D 2017-10-09 [AR] [expires: 2018-10-09]
gpg
Martin Hope
lopass
Asked: 2022-09-29 12:54:47 +0800 CST
  • 0

Eu tenho um trabalho que pega arquivos CSV e os envia por meio de um serviço de correio externo. Tudo parece estar ótimo, com uma exceção: descobri que os arquivos CSV CRLF estilo Windows são danificados pelo processo e quando os abro em um cliente de email, eles têm 3 caracteres 0x0A no final de cada linha.

Eu pensei que seria fácil forçar a codificação base64 dos arquivos, mas embora pareça que o s-nail deveria ser uma Ferrari do ponto de vista da programação, não consigo encontrar o pedal do acelerador. Brincando com as configurações de mime, posso alterar o tipo de conteúdo, mas obter a carga útil para a base 64 simplesmente não está acontecendo.

echo "CSV files attached:" | s-nail -vv -Smimetypes-load-control -X'mimetype "application/octet-stream csv"'  -r [email protected] -s "Your CSV file" -a /data/review/fun.csv  -S smtp-use-starttls -S smtp-auth=login -S smtp-auth-user="[email protected]" -S smtp-auth-password="yourmom" -S smtp="corgibutts.com:587" "[email protected]"

Alguém tem alguma ideia de como fazer isso acontecer?

email base64
Martin Hope
lopass
Asked: 2018-01-06 14:51:42 +0800 CST
  • 5

Estou usando um yubikey nano em meu sistema local para criptografar/descriptografar/assinar em sistemas remotos, além de encaminhamento de agente SSH. Lembro-me de ser difícil de configurar, mas funcionou perfeitamente por vários meses. De repente quebrou. Todas as minhas pesquisas retornam os mesmos links que li quando o configurei, mas estou travado.

O encaminhamento do agente SSH funciona inexplicavelmente. O sistema remoto mostra isso:

REMOTE:$ ssh-add -L
ssh-rsa blahblah cardno:123

Posso fazer login em outros servidores usando SSH do sistema remoto e ele usa o nano para autenticação (sei disso porque requer toque para habilitar a assinatura do agente). Posso ver logs sobre a assinatura SSH no log gpg-agent no sistema local.

No entanto, não consigo fazer com que a assinatura/criptografia do GPG funcione. Se eu executar o seguinte no sistema remoto:

REMOTE:$ echo "$(uname -a)" |  gpg2 --armor --clearsign --default-key 0x1234
gpg: all values passed to '--default-key' ignored
gpg: no default secret key: No secret key
gpg: [stdin]: clearsign failed: No secret key

No log local do agente gpg, não vejo nenhum log sobre a tentativa. Se eu executar este comando, posso ver as entradas de log no log local do gpg-agent:

REMOTE:$ $ netcat  -U /home/user/.gnupg/S.gpg-agent
OK Pleased to meet you
RESET
OK
GETINFO PID
ERR 67109115 Forbidden <GPG Agent>
POOP
ERR 67109139 Unknown IPC command <GPG Agent>

O que resulta nesses logs no agente local:

2018-01-05 16:38:32 gpg-agent[865] DBG: chan_10 -> OK Pleased to meet you
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 <- RESET
2018-01-05 16:38:35 gpg-agent[865] DBG: chan_10 -> OK
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 <- GETINFO PID
2018-01-05 16:38:45 gpg-agent[865] DBG: chan_10 -> ERR 67109115 Forbidden <GPG Agent>
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 <- POOP
2018-01-05 16:39:01 gpg-agent[865] DBG: chan_10 -> ERR 67109139 Unknown IPC command <GPG Agent>

Se eu executar strace -f -F em gpg-connect-agent no sistema remoto, ele parece estar se conectando a um soquete em /var/run, mas não aquele encaminhado do sistema local em ~/.gnupg/. Eu tentei remover ambos os soquetes, matando todos os processos do gpg-agent e mudei o encaminhamento remoto SSH para ir para o local /var/run ou ~/.gnupg sem sucesso. É possível que eu estraguei essas etapas e as tentarei novamente, mas quero saber se alguém sabe a resposta e gostaria de ter uma postagem fácil de encontrar para a próxima vez que isso quebrar.

SISTEMA LOCAL:

Mac OS X 10.11.6
gpg installed with brew
gpg (GnuPG) 2.2.1
libgcrypt 1.8.1

SISTEMA REMOTO:

ubuntu 17.10
gpg (GnuPG) 2.1.15
libgcrypt 1.7.8

EDIT: Ok, não faço ideia do que mudou, mas deixei quieto um pouco e voltei e tentei trocar o soquete novamente e agora funciona:

REMOTE:$ $ echo "$(uname -a)" |  strace -f -F gpg2 --armor --clearsign --default-key 0x1234
...
a bunch of garbage
...
stat("/run/user/1000/gnupg/S.gpg-agent", {st_mode=S_IFSOCK|0600, st_size=0, ...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 5

Mudar meu encaminhamento remoto SSH para este novo local funcionou. Juro que tentei isso anteriormente usando o caminho do soquete fornecido por gpgconf --list-dir agent-ssh-socket, sem sorte. Provavelmente esqueceu de matar o agente existente. E por acaso, acabei de encontrar uma postagem no blog relatando que isso mudou: https://blog.kylemanna.com/linux/gpg-213-ssh-agent-socket-moved/

linux ssh