Questão Usando a diretiva IdentityFile em ssh_config quando o AgentForwarding está em uso


É possível especificar chaves encaminhadas usando a diretiva IdentityFile em .ssh / config?

Eu corri para este truque ao tentar implantar algum código via Capistrano / GIT em nosso servidor de produção. As minhas chaves GIT pessoais e do meu trabalho são sempre carregadas no meu agente SSH e acontece que a minha chave pessoal foi adicionada primeiro ao agente. Eu uso o encaminhamento de agentes ao implantar com o Capistrano, então quando o host tentou autenticar a operação `git pull` ele falhou com o seguinte erro:

ERRO: Permissão para `algum repo` negado ao` seu usuário`.

porque tentou autenticar usando minha chave git pessoal antes de tentar a chave apropriada (que veio depois no agente ssh) e assumiu que eu estava acessando um repositório estrangeiro que eu não tenho permissão para acessar. Eu posso, potencialmente, apenas dar ao meu usuário pessoal acesso a cada repositório de trabalho, mas na minha máquina local eu posso contornar este problema definindo domínios personalizados em .ssh / config da seguinte forma:

Hospedeiro personal.github.com
nome de anfitrião github.com
Do utilizador git
IdentityFile ~ / .ssh / some_key

Hospedeiro work.github.com
nome de anfitrião github.com
Do utilizador git
IdentityFile ~ / .ssh / some_other_key

e assim nunca fica confuso. É possível criar regras de .ssh / config para chaves encaminhadas em minhas caixas de produção para que elas sempre saibam qual chave usar ao inserir um novo código? Basicamente eu quero ser capaz de fazer:

Hospedeiro work.github.com
nome de anfitrião github.com
Do utilizador git
IdentityFile some_forwarded_key

Obrigado!


14


origem




Respostas:


Você pode usar a parte pública de uma chave para especificar qual chave privada você deseja usar do agente encaminhado. Isso requer a criação de um arquivo extra (a parte pública da chave) em qualquer máquina “intermediária” (máquinas para as quais você encaminha seus dados locais). ssh-agent).

  1. Providencie para que a máquina intermediária tenha uma cópia da parte pública da chave desejada em um local conveniente (por exemplo, ~/.ssh/some_other_key.pub).

    De qualquer máquina que já tenha a parte pública da chave:

    scp some_other_key.pub intermediate:.ssh/
    

    ou, na máquina intermediária:

    ssh-add -L | grep something_unique > ~/.ssh/some_other_key.pub
    

    Você pode editar a parte "de comentários" da chave pública para identificar melhor a origem / proprietário / propósito da chave (ou tentar ocultá-la).

  2. Use o nome do caminho para o arquivo de chave pública acima com -i ou IdentityFile.

  3. Você também pode precisar usar IdentitiesOnly yes (dentro .ssh/config ou -o) manter ssh de tentar oferecer quaisquer identidades adicionais do seu agente encaminhado.


21



Esta é a única coisa que funcionou para mim a partir de 10 outras soluções. - Tracy Fu
Brincando com isso, percebi que se você colocar a chave pública associada à chave privada que deseja usar em ~ / .ssh / id_rsa.pub na máquina intermediária, ela será usada por padrão, sem necessidade de qualquer configuração em ~ / .ssh / config. - bschlueter
Obrigado Chris e bschlueter! Eu agora me conecto com: ssh someserver -t "ssh-add -L | grep algo_unique> ~ / .ssh / id_rsa.pub; cd alguma / outra / pasta; bash --login" - blablabla
Quando eu tento isso com ssh -v -T ... o servidor aceita a chave pública, mas depois o ssh diz No such identity: /home/name/.ssh/id_rsa: No such file or directorye, subsequentemente, a autenticação falha. Eu tenho o ForwardAgent habilitado em todas as minhas configurações. Qual poderia ser o problema? - Lars Nyström