Encaminhamento de acesso a um subconjunto de identidades do ssh-agent

Question

Eu trabalho para duas empresas (vamos chamá-las de RedCorp e BlueCorp). Ambos confiam em mim, mas não confiam um no outro, e eu não quero expor os segredos de um para o outro.

O ssh-agent do meu laptop tem duas chaves privadas, uma para o acesso a cada empresa. Posso correr:

ssh -A redcorp-server1

e acessar todos os outros servidores da redcorp de lá, em virtude da conexão do meu agente encaminhado.

Da mesma forma, posso executar:

ssh -A bluecorp-server1

e acessar todos os outros servidores da bluecorp a partir dali.

O problema é que sempre que eu estou logado no redcorp-server1, o usuário root lá pode definir o seu $ SSH_AUTH_SOCK para apontar para a minha conexão de agente encaminhado, e abusar da minha outra identidade para invadir a BlueCorp.

Como posso evitar isso?

A opção IdentitiesOnly do ssh não faz o que eu quero. Isso controla apenas qual chave eu ofereço ao autenticar para redcorp-server1; isso não muda o fato de que minha conexão de agente redirecionado permite que um processo ssh em redcorp-server1 seja autenticado usando qualquer uma das minhas identidades.

A única solução que encontrei é executar dois agentes ssh separados e carregar apenas uma chave em cada um deles. Isso é uma grande dor: não há como uma estrofe ssh_config especificar quais dos meus agentes eu devo usar quando me conectar a um determinado host. Em vez disso, tive que fazer aliases de shell no meu laptop para cada um dos dois corpos que apontam $ SSH_AUTH_SOCK para o agente correto antes de executar o ssh. Além disso, eu uso o rsync e uma dúzia de outras ferramentas que usam o ssh como um transporte, e cada uma delas tem que ser configurada usando uma sintaxe diferente para fazer com que invoque o ssh desta maneira especial.

Existe uma maneira melhor de fazer isso?

    

Answer 1

Eu implementei um ssh-agent-filter para mim, use-o com:

$ afssh -c id_bluecorp -- server1.bluecorp.com
$ afssh -c id_bluecorp -- server2.bluecorp.com
$ afssh -c id_redcorp -- server42.redcorp.com

Já está no Debian (e no Ubuntu).

    

Answer 2

Existe um patch para o openssh que encaminhará o ssh-agent especificado pela variável de ambiente SSH_AUTH_SOCK_FORWARD para o host remoto e usará o usual SSH_AUTH_SOCK env. var. agente para autenticação no host.

Isso significa que você pode usar o filtro ssh-agent para filtrar apenas a chave que deseja disponibilizar na máquina remota e alterar o env. var do filtro ssh-agent para SSH_AUTH_SOCK_FORWARD , deixando todas as suas chaves no agente SSH_AUTH_SOCK .

Você pode encontrar o patch aqui:

link

Espero que seja aplicado ao openssh.

    

Answer 3

Eu não entendo o problema. Se você definir e exportar $ SSH_AUTH_SOCK para o valor apropriado, os programas que chamarem ssh não precisarão de nenhuma modificação. Obviamente, o alvo de, e. uma chamada de rsync deve ser compatível com a seleção do agente ssh.