Como encaminhar uma chave gpg via ssh-agent?

Posso usar o arquivo de configuração ssh para habilitar o encaminhamento de chaves ssh adicionadas ao ssh-agent. Como posso fazer o mesmo com as teclas gpg?

EDIT: Esta resposta está obsoleta agora que o suporte adequado foi implementado no OpenSSH, consulte a resposta de Brian Minton.

O SSH é capaz apenas de encaminhar conexões TCP dentro do túnel.

Você pode, no entanto, usar um programa como o socatde retransmitir o soquete unix pelo TCP, com algo assim (você precisará socat nos hosts do cliente e do servidor):

# Get the path of gpg-agent socket:
GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1)

# Forward some local tcp socket to the agent
(while true; do
    socat TCP-LISTEN:12345,bind=127.0.0.1 UNIX-CONNECT:$GPG_SOCK;
done) &

# Connect to the remote host via ssh, forwarding the TCP port
ssh -R12345:localhost:12345 host.example.com

# (On the remote host)
(while true; do
    socat UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early TCP4:localhost:12345;
done) &

Teste se funciona com gpg-connect-agent. Verifique se GPG_AGENT_INFO está indefinido no host remoto, para que ele volte ao $HOME/.gnupg/S.gpg-agentsoquete.

Agora espero que tudo que você precisa seja uma maneira de executar tudo isso automaticamente!

O novo Unix Domain Socket Forwarding do OpenSSH pode fazer isso diretamente a partir da versão 6.7.

Você deve ser capaz de algo como:

ssh -R /home/bminton/.gnupg/S.gpg-agent:/home/bminton/.gnupg/S-gpg-agent -o "StreamLocalBindUnlink=yes" -l bminton 192.168.1.9

Nas novas versões das distribuições GnuPG ou Linux, os caminhos dos soquetes podem mudar. Estes podem ser encontrados através de

$ gpgconf --list-dirs agent-extra-socket

e

$ gpgconf --list-dirs agent-socket

Em seguida, adicione esses caminhos à sua configuração SSH:

Host remote
  RemoteForward <remote socket> <local socket>

Solução rápida para copiar as chaves públicas:

scp .gnupg/pubring.kbx remote:~/.gnupg/

Na máquina remota, ative o agente GPG:

echo use-agent >> ~/.gnupg/gpg.conf

Na máquina remota, modifique também a configuração do servidor SSH e adicione este parâmetro (/ etc / ssh / sshd_config):

StreamLocalBindUnlink yes

Reinicie o servidor SSH, reconecte-se à máquina remota - então deve funcionar.

Eu tive que fazer o mesmo e baseei meu script na solução por b0fh, com algumas pequenas modificações: ele captura e fecha processos em segundo plano e usa as opções "fork" e "reuseaddr" para socat, o que poupa a você loop (e torna o plano de fundo socat perfeitamente capaz de matar).

A coisa toda configura todos os encaminhamentos de uma só vez, por isso provavelmente se aproxima de uma configuração automatizada.

Observe que no host remoto, você precisará de:

1. Os chaveiros que você pretende usar para assinar / en / descriptografar as coisas.
2. Dependendo da versão do gpg no controle remoto, uma GPG_AGENT_INFOvariável falsa . Eu prefiro o meu ~/.gnupg/S.gpg-agent:1:1- o primeiro 1 é um PID para o agente gpg (eu o invoco como "init", que está sempre em execução), o segundo é o número da versão do protocolo do agente. Isso deve corresponder ao que está sendo executado na sua máquina local.

#!/bin/bash -e

FORWARD_PORT=${1:-12345}

trap '[ -z "$LOCAL_SOCAT" ] || kill -TERM $LOCAL_SOCAT' EXIT

GPG_SOCK=$(echo "$GPG_AGENT_INFO" | cut -d: -f1)
if [ -z "$GPG_SOCK" ] ; then
    echo "No GPG agent configured - this won't work out." >&2
    exit 1
fi

socat TCP-LISTEN:$FORWARD_PORT,bind=127.0.0.1,reuseaddr,fork UNIX-CONNECT:$GPG_SOCK &
LOCAL_SOCAT=$!

ssh -R $FORWARD_PORT:127.0.0.1:$FORWARD_PORT socat 'UNIX-LISTEN:$HOME/.gnupg/S.gpg-agent,unlink-close,unlink-early,fork,reuseaddr TCP4:localhost:$FORWARD_PORT'

Acredito que também exista uma solução que envolva apenas uma chamada de comando SSH (conectando-se novamente do host remoto ao local) -o LocalCommand, mas não consegui descobrir como matá-lo convenientemente na saída.

De acordo com o GnuPG Wiki , você deve encaminhar o soquete remoto S.gpg-agent.extrapara o soquete local S.gpg-agent. Além disso, você precisa habilitar StreamLocalBindUnlinkno servidor.
Lembre-se de que você também precisa da parte pública da sua chave disponível no GnuPG remoto .

Use gpgconf --list-dir agent-socketrespectivamente gpgconf --list-dir agent-extra-socketno controle remoto para obter os caminhos reais.

Sumário

1. Configuração adicionada no controle remoto /etc/sshd_config:

   StreamLocalBindUnlink yes
   

2. Importe sua chave pública no controle remoto:

   gpg --export <your-key> >/tmp/public
   scp /tmp/public <remote-host>:/tmp/public
   ssh <remote-host> gpg --import /tmp/public
   

3. Comando para conectar-se através do SSH com o encaminhamento do gpg-agent ativado: (caminhos para o meu Debian)

   ssh -R /run/user/1000/gnupg/S.gpg-agent:/run/user/1000/gnupg/S.gpg-agent.extra <remote-host>
   

Como uma alternativa para modificar /etc/ssh/sshd_configcom StreamLocalBindUnlink yes, você, em vez pode impedir a criação dos arquivos de soquete que precisam de substituição:

systemctl --global mask --now \
  gpg-agent.service \
  gpg-agent.socket \
  gpg-agent-ssh.socket \
  gpg-agent-extra.socket \
  gpg-agent-browser.socket

Observe que isso afeta todos os usuários no host.

Bônus: Como testar o encaminhamento do agente GPG está funcionando:

• Local: ssh -v -o RemoteForward=${remote_sock}:${local_sock} ${REMOTE}
• Verifique se ${remote_sock}é mostrado na saída detalhada do ssh
• Controlo remoto: ls -l ${remote_sock}
• Controlo remoto: gpg --list-secret-keys
  • Você deve ver muitas debug1mensagens do ssh mostrando o tráfego encaminhado

Se isso não funcionar (como não aconteceu comigo), você pode rastrear qual soquete o GPG está acessando:

strace -econnect gpg --list-secret-keys

Saída de amostra:

connect(5, {sa_family=AF_UNIX, sun_path="/run/user/14781/gnupg/S.gpg-agent"}, 35) = 0

No meu caso, o caminho que está sendo acessado corresponde perfeitamente ${remote_sock}, mas esse soquete não foi criado sshdquando eu entrei, apesar de adicionar StreamLocalBindUnlink yesao meu /etc/ssh/sshd_config. Eu fui criado pelo systemd no login.

(Observe que eu era covarde demais para reiniciar o sshd, pois não tenho acesso físico ao host no momento. service reload sshdClaramente não era suficiente ...)

Testado no Ubuntu 16.04