Usando a mesma chave de implantação para vários projetos github

92

O Github não permite que a mesma chave de implantação ssh seja usada para mais de um projeto, o que seria muito útil em alguns casos (por exemplo, servidor de CI lidando com projeto com submódulos privados). Já vi vários tópicos que parecem dizer que essa limitação existe por 'razões de segurança', mas ainda estou para ver uma explicação convincente sobre exatamente qual risco isso aumentaria.

Observe que o fato de que o Github não permite que chaves de nível de conta sejam reutilizadas faz sentido (dois usuários não devem compartilhar chaves). É apenas a restrição de Implementar Chaves que estou questionando.

E para ser claro, eu estou não à procura de soluções alternativas (criar um usuário fictício, utilize várias chaves, ...), mas apenas para uma explicação plausível para essa limitação em Implantar Keys.

Tópicos relacionados:

git  github  ssh 
— David Ebbo
fonte
Como não há maneira melhor, criamos um usuário de implantação dedicado a quem estamos concedendo acesso somente leitura aos repositórios. O resultado final é o mesmo.
— Datageek
— apple16

Respostas:

22

O único motivo, ilustrado pela solução alternativa que você faz referência (criar um único usuário de "compilação" ou compartilhar o mesmo id_rsa.REPONAME.pubpor repo) é:

evite compartilhar chaves públicas / privadas para usuários diferentes

Mesmo que não seja o caso em sua situação (construir vários projetos), permitir a reutilização da mesma chave ssh abriria a possibilidade para dois usuários diferentes compartilharem a mesma chave ssh, o que anularia o propósito de autenticação .

Autenticação significa:
"usar uma determinada chave ssh deve implicar que você sabe quem a está usando".

A página do GitHub " Gerenciando chaves de implantação " detalha as várias contas usando ssh:

  • Encaminhamento de agente SSH : o encaminhamento de agente usa as chaves SSH já configuradas em sua máquina de desenvolvimento local quando você faz SSH em seu servidor e executa comandos git.
    Você pode permitir seletivamente que servidores remotos acessem seu agente ssh local como se ele estivesse em execução no servidor.
    Portanto, não há necessidade de replicar sua chave privada no servidor.

  • Usuários da máquina : (esta é a estratégia de "conta fictícia") Anexe a chave a uma conta de usuário. Como essa conta não será usada por um humano, é chamada de usuário da máquina.
    No entanto, você trataria esse usuário da mesma forma que trataria um humano, anexando a chave à conta do usuário da máquina como se fosse uma conta normal.
    Conceda ao colaborador da conta ou à equipe acesso aos repositórios aos quais ele precisa acessar.
    Portanto, uma chave privada associada a um "usuário da máquina", uma por servidor.

( DHa aponta nos comentários para um número limite de chave de implantação e o fato de você poder ter apenas uma conta de usuário de máquina)

  • Implante a chave (uma por repositório GitHub) a chave SSH que é armazenada no servidor e concede acesso a um único repo no GitHub.
    Essa chave é anexada diretamente ao repo em vez de a uma conta de usuário .
    Em vez de acessar as configurações da sua conta, vá para a página de administração do repo de destino.
    Vá para " Deploy Keys" e clique em " Add deploy key". Cole a chave pública e envie.

Desta vez, a chave ssh não está anexada a um usuário (para o qual você pode conceder acesso a vários repo), mas a um repo.
Conceder acesso ssh a vários repo seria o equivalente a um "usuário de máquina".

Em termos de autenticação :

  • usar a mesma chave para vários repositórios está correto quando é feito por um usuário (que tem essa chave associada à sua conta)
  • usar a mesma chave para vários repo NÃO é bom quando a chave é anexada por um repo, porque você não sabe quem acessou o quê.
    Isso difere do "usuário da máquina", onde um "usuário" é declarado como colaborador de muitos repo.
    Aqui (chave de implantação), não há "colaborador" , apenas um acesso direto ssh concedido ao repo.
— VonC
fonte
53
O GitHub é compatível com chaves públicas de nível de conta e chaves de nível de projeto (também conhecidas como chaves de implantação). Não permitindo a reutilização de Conta Nível de chaves faz sentido, mas eu afirmo que não permitindo que ele para Implantar Chaves não. Minha única chave de nível de conta permite acesso a todos os meus projetos, então por que não poderia ter uma chave de implantação que permite acesso a alguns de meus projetos? É apenas mais restritivo e não cria nenhuma preocupação que eu possa ver. Sua preocupação em abrir a possibilidade de dois usuários diferentes compartilharem a mesma chave ssh não aparece nesse cenário.
— David Ebbo
@DavidEbbo Pode não aparecer, mas essa preocupação (dois usuários diferentes compartilham a mesma chave ssh) está no cerne da razão pela qual uma chave ssh não é compartilhada.
— VonC
21
Receio não seguir seu raciocínio aqui. Estou perguntando sobre um cenário muito específico (use uma chave de implantação em vários projetos), e seu argumento para que isso não seja possível é apresentar um cenário não relacionado (dois usuários compartilhando chaves ssh). Ficando exclusivamente com o cenário Deploy Key, qual seria o negativo de o github permitir isso?
— David Ebbo
6
@DavidEbbo Seguindo help.github.com/articles/managing-deploy-keys , nenhum dos três métodos (conta, implantação ou contas de máquina) envolve o compartilhamento de uma chave SSH privada para acessar os referidos repositórios. Ficar exclusivamente com o cenário Deploy Key, uma vez que é uma chave no servidor , para ser válido em vários repos significaria compartilhar (ou replicar) uma chave privada em vários repos. Isso diminui o aspecto da autenticação e, se a chave for comprometida, aumenta o número de repositórios expostos.
— VonC
8
obrigado, essa página tem informações interessantes. Vou marcar sua resposta como a resposta em um ou dois dias se não vir mais nada, embora, para ser honesto, ainda não estou convencido pelo argumento. Ter uma chave de implantação usada em dois repos não é mais fraco do que usar uma chave de máquina que tem acesso ao mesmo conjunto de repos.
— David Ebbo
10

Infelizmente, este é um cenário em que o github apenas interpreta mal a distinção entre um par de chaves e uma conta ou projeto.

Como um par de chaves é usado para autenticação e autorização, ele é efetivamente uma identidade. As contas do Github são outra identidade. Conectar contas github a pares de chaves estabelece efetivamente um mapeamento 1: N entre identidades baseadas em contas github e identidades de pares de chaves.

Por outro lado, o github impõe um mapeamento 1: N de projetos para identidades baseadas em pares de chaves. O análogo do mundo real é que há uma porta que dá acesso ao projeto que pode ser destrancada por muitas pessoas diferentes. Mas uma vez que qualquer um deles consegue a chave da porta, eles não podem obter nenhuma outra chave para nenhuma outra porta, nunca mais.

Faz sentido não reutilizar as chaves com frequência da perspectiva de conter violações se uma chave for comprometida. Mas essa é apenas uma boa política de administração . Não faz muito sentido evitar que uma chave seja usada mais de uma vez, por princípio . Que existem algumas chaves para algumas portas que nunca são reutilizadas, bem, de novo, isso é uma questão de política .

Uma visão um pouco mais complexa é ilustrar os pares de chaves como papéis . Você pode possuir muitos pares de chaves e, portanto, desempenhar muitas funções. A chave privada autentica você para a função.

O mapeamento de chaves de implantação do Github para projetos afirma que uma função nunca pode abranger mais de uma tarefa. Isso raramente é realista.

Nada disso muda o que o github permite, é claro.

— Jens Finkhaeuser
fonte
1
Heh. É engraçado como isso é rejeitado, quando é mais correto do que a resposta aceita. Não há literalmente nada nisso que impeça o compartilhamento de uma chave com vários usuários.
— Jens Finkhaeuser
2

Levei muito pensamento para racionalizar as implicações e chegar a esse cenário.

Imagine que você crie uma única chave de implantação para um usuário que você atribuiu a vários repositórios. Agora você deseja revogar essa chave, mas ela é usada em vários lugares. Portanto, em vez de revogar todo o acesso, você pode inadvertidamente revogar apenas o acesso parcial.

Isso pode parecer um benefício, mas esse relacionamento de muitos para um é, na verdade, inerentemente inseguro, se você considerar o fator humano. Isso ocorre porque você não pode saber com certeza se realmente revogou todo o acesso sem inspecionar cada repositório e comparar cada chave pública individualmente, caso tenha esquecido de onde realmente a atribuiu.

É definitivamente frustrante atribuir e gerenciar tantas chaves exclusivas, mas as implicações de segurança são claras com a forma como o GitHub instituiu sua política: quando você revoga uma chave, está garantido que estará revogando todo o acesso concedido por essa chave porque ela é usada apenas em um lugar .

— Zhro
fonte
1
Não estou convencido por esta explicação. Como isso difere fundamentalmente de permitir que um usuário acesse vários repositórios, o que é obviamente permitido? Se você não confia mais nesse usuário, precisa removê-lo de cada repositório.
— David Ebbo
@David: How is that fundamentally different from allowing one user to access multiple repositories, which is obviously allowedVocê pode explicar isso melhor? Eu só tenho uma conta de desenvolvedor e vejo que você pode adicionar chaves SSH para acesso de toda a conta (uma chave para todos os repositórios) ou adicionar chaves de implantação individuais (uma chave para cada repositório). Este ainda é um relacionamento um-para-muitos ou um-para-um em que revogar a tecla "um" revoga o acesso "todos" em ambos os casos.
— Zhro de
Para esclarecer ainda mais, não há oportunidade (o que posso dizer) de atribuir acidentalmente uma chave em um relacionamento muitos para um em que o acesso pode existir em outro lugar depois de ser revogado. Esta parece ser a motivação do GitHub para essa restrição, mas estou apenas supondo.
— Zhro de
Do jeito que eu vejo as coisas, as chaves de implantação são um pouco como 'usuários anônimos' que não têm uma conta completa, mas ainda representam algum tipo de identidade. A diferença é que, no caso da conta, você dá acesso à conta, o que indiretamente dá acesso a todas as chaves ssh dessa conta. Enquanto no caso Deploy Key, você pula a abstração da conta e dá acesso direto à chave ssh. Mas, além disso, não vejo as necessidades de segurança sendo diferentes. Se a conta OU o proprietário da chave de implantação se tornar mal, você precisará removê-los de cada repo.
— David Ebbo de
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.