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/
Há claramente um bug aqui que é intermitente ou é um efeito colateral de como todos esses sistemas interagem juntos. Não quero entrar em muitos detalhes/conjecturas, mas consideraria o seguinte:
Uma ótima solução seria usar um host separado e especial em .ssh/config para o encaminhamento do agente gpg e certifique-se de usar o login para esse nome de host apenas uma vez!
As poucas vezes que isso aconteceu foram muito frustrantes porque a combinação de pipes/agentes em execução e instâncias em que uma nova sessão sshd não criou novos soquetes levou a todo tipo de confusão (novamente possivelmente devido a arquivos de soquete antigos mantidos abertos por um agente em execução ). E geralmente, não tenho tempo para tentar consertar esse problema.
Tendo finalmente encontrado isso onde eu estava em posição de solucionar e corrigir, posso reproduzir o problema de forma confiável e mostrar como corrigi-lo:
Sistema de trabalho
Execute outro SSH ou Rsync do sistema local
O SCP não causa problemas, mas o RSYNC claramente faz um login ssh, pois vejo que os encaminhamentos de porta falham quando o arquivo é copiado
A criptografia/descriptografia remota agora falha
O conserto
Para as etapas 3 e 4, eu vi ir nos dois sentidos, às vezes os canos permanecem e às vezes eles desaparecem adequadamente. Também pode ser necessário remover os arquivos pipe e fazer login novamente e garantir que eles sejam recriados.
Tudo agora deve funcionar novamente para criptografia/descriptografia
ATUALIZAÇÃO - CORREÇÃO MAIS SIMPLES
Hoje isso aconteceu sem rima ou motivo, e fiquei bastante irritado. Eu tive que encontrar este post e estava com preguiça de fazer tudo o que meu post original estava me dizendo para fazer para consertar. Considerei a situação da perspectiva de minhas conjecturas acima. Para encurtar a história, isso funcionou:
Tudo estava funcionando novamente