Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.
Enterprise Server 3.0
Português do Brasil
� 
Developers
Enterprise Server 3.0
Português do Brasil

� 

Esta versão do GitHub Enterprise foi descontinuada em 2022-02-16. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

Gerenciar chaves de implantação

Neste artigo

Aprenda maneiras diferentes de gerenciar chaves SSH em seus servidores ao automatizar scripts de implantação e da melhor maneira para você.

Você pode gerenciar chaves SSH em seus servidores ao automatizar scripts de implantação usando o encaminhamento do agente SSH, HTTPS com tokens do OAuth, chaves de implantação ou usuários de máquina.

Encaminhamento de agente SSH

Em muitos casos, especialmente no início de um projeto, o encaminhamento de agentes SSH é o método mais rápido e simples de utilizar. O encaminhamento de agentes usa as mesmas chaves SSH que o seu computador de desenvolvimento local.

Prós

  • Você não tem que gerar ou monitorar nenhuma chave nova.
  • Não há gerenciamento de chaves; os usuários têm as mesmas permissões no servidor e localmente.
  • Não há chaves armazenadas no servidor. Portanto, caso o servidor esteja comprometido, você não precisa buscar e remover as chaves comprometidas.

Contras

  • Os usuários devem ingressar com SSH para implantar; os processos de implantação automatizados não podem ser usados.
  • Pode ser problemático executar o encaminhamento de agente SSH para usuários do Windows.

Configuração

  1. Ativar o encaminhamento do agente localmente. Consulte o nosso guia sobre o encaminhamento de agentes SSH para obter mais informações.
  2. Defina seus scripts de implantação para usar o encaminhamento de agentes. Por exemplo, em um script bash, permitir o encaminhamento de agentes seria algo como isto: ssh -A serverA 'bash -s' < deploy.sh

Clonagem de HTTPS com tokens do OAuth

Se você não quiser usar chaves SSH, você poderá usar HTTPS com tokens OAuth.

Prós

  • Qualquer pessoa com acesso ao servidor pode implantar o repositório.

  • Os usuários não precisam alterar suas configurações SSH locais.

  • Não são necessários vários tokens (um para cada usuário); um token por servidor é suficiente.

  • Um token pode ser revogado a qualquer momento, transformando-o, basicamente, em uma senha de uso único.

  • Gerar novos tokens pode ser facilmente programado usando a API do OAuth.

Contras

  • Você deve certificar-se de configurar seu token com os escopos de acesso corretos.
  • Os Tokens são, basicamente, senhas e devem ser protegidos da mesma maneira.

Configuração

Consulte nosso guia sobre a criação de um token de acesso pessoal.

Chaves de implantação

You can launch projects from a repository on your GitHub Enterprise Server instance to your server by using a deploy key, which is an SSH key that grants access to a single repository. GitHub Enterprise Server anexa a parte pública da chave diretamente ao repositório em vez de uma conta de usuário pessoal, e a parte privada da chave permanece no seu servidor. Para obter mais informações, consulte "Entregar implantações".

As chaves de implantação com acesso de gravação podem realizar as mesmas ações que um integrante da organização com acesso de administrador ou um colaborador em um repositório pessoal. For more information, see "Repository roles for an organization" and "Permission levels for a user account repository."

Prós

  • Qualquer pessoa com acesso ao repositório e servidor é capaz de implantar o projeto.
  • Os usuários não precisam alterar suas configurações SSH locais.
  • As chaves de implantação são somente leitura por padrão, mas você pode lhes conferir acesso de gravação ao adicioná-las a um repositório.

Contras

  • As chaves de implementação só concedem acesso a um único repositório. Projetos mais complexos podem ter muitos repositórios para extrair para o mesmo servidor.
  • De modo geral, as chaves de implantação não são protegidas por uma frase secreta, o que a chave facilmente acessível se o servidor estiver comprometido.

Configuração

  1. Execute o procedimento ssh-keygen no seu servidor e lembre-se o local onde você salvou o par de chaves da chave da rsa pública e privada.
  2. No canto superior direito de qualquer página do GitHub Enterprise Server, clique na sua foto do perfil e, em seguida, clique em Seu perfil. Navegação para o perfil
  3. Na sua página de perfil, clique em Repositórios e, em seguida, clique no nome do seu repositório. Link dos repositórios
  4. No seu repositório, clique em Configurações. Configurações do repositório
  5. Na barra lateral, clique em Implantar Chaves e, em seguida, clique em Adicionar chave de implantação. Link para adicionar chaves de implantação
  6. Forneça um título e cole na sua chave pública. Página da chave implantação
  7. Selecione Permitir acesso de gravação, se você quiser que esta chave tenha acesso de gravação no repositório. Uma chave de implantação com acesso de gravação permite que uma implantação faça push no repositório.
  8. Clique em Adicionar chave.

Usar vários repositórios em um servidor

Se você usar vários repositórios em um servidor, você deverá gerar um par de chaves dedicado para cada um. Você não pode reutilizar uma chave de implantação para vários repositórios.

No arquivo de configuração do SSH do servidor (geralmente ~/.ssh/config), adicione uma entrada de pseudônimo para cada repositório. Por exemplo:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 - O alias do repositório.
  • Hostname my-GHE-hostname.com - Configura o nome de host a ser usado com o alias.
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key - Atribui uma chave privada ao pseudônimo.

Em seguida, você pode usar o apelido do host para interagir com o repositório usando SSH, que usará a chave de deploy exclusiva atribuída a esse pseudônimo. Por exemplo:

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

Tokens do servidor para servidor

Se seu servidor precisar acessar repositórios em uma ou mais organizações, você poderá usar um aplicativo GitHub para definir o acesso que você precisa e, em seguida, gerar tokens de escopo limitado, servidor para servidor a partir daquele aplicativo GitHub. Os tokens do servidor para servidor podem ter escopo de repositório único ou múltiplo e podem ter permissões refinadas. Por exemplo, você pode gerar um token com acesso somente leitura para o conteúdo de um repositório.

Uma vez que os aplicativos GitHub são um ator de primeira classe em GitHub Enterprise Server, os tokens do servidor para servidor são dissociados de qualquer usuário do GitHub, o que os torna comparáveis aos "tokens de serviço". Além disso, tokens de servidor para servidor têm limites de taxa dedicados que escalam com o tamanho das organizações sobre as quais eles atuam. Para obter mais informações, consulte Limites de taxa para os aplicativos Github.

Prós

  • Tokens com escopo limitado com conjuntos de permissões bem definidos e tempos de expiração (1 hora, ou menos se for revogado manualmente usando a API).
  • Limites de taxa dedicados que crescem com a sua organização.
  • Separados das identidades de usuários do GitHub para que não consumam nenhuma estação licenciada.
  • Nunca concedeu uma senha. Portanto, não pode efetuar o login diretamente.

Contras

  • É necessária uma configuração adicional para criar o aplicativo GitHub.
  • Os tokens de servidor para servidor expiram após 1 hora. Portanto, precisam ser gerados novamente, geralmente sob demanda e usando código.

Configuração

  1. Determine se seu aplicativo GitHub deve ser público ou privado. Se o seu aplicativo GitHub agir apenas nos repositórios da organização, é provável que você queira que ele seja privado.
  2. Determine as permissões que o aplicativo GitHub exige, como acesso somente leitura ao conteúdo do repositório.
  3. Crie seu aplicativo GitHub por meio da página de configurações da sua organização. Para obter mais informações, consulte Criar um aplicativo GitHub.
  4. Observe seu id id do aplicativo GitHub.
  5. Gere e faça o download da chave privada do seu aplicativo GitHub e armazene-a com segurança. Para obter mais informações, consulte Gerar uma chave privada.
  6. Instale o aplicativo GitHub nos repositórios nos quais ele precisa agir. Opcionalmente você poderá instalar o aplicativo GitHub em todos os repositórios da sua organização.
  7. Identifique o installation_id que representa a conexão entre o aplicativo GitHub e os repositórios da organização �  qual ele pode acessar. Cada aplicativo GitHub e par de organização tem, no máximo, um installation_id único. Você pode identificar este installation_id por meio de Obter uma instalação da organização para o aplicativo autenticado. Isto exige autenticação como um aplicativo GitHub usando um JWT. Para obter mais informações, consulte Efetuar a autenticação como um aplicativo GitHub.
  8. Gere um token de servidor para servidor usando o ponto de extremidade correspondente da API REST, Crie um token de acesso de instalação para um aplicativo. Isto exige autenticação como um aplicativo GitHub usando um JWT. Para obter mais informações, consulte Efetuar a autenticação como um aplicativo GitHub e Efetuar a autenticação como uma instalação.
  9. Use este token de servidor para servidor para interagir com seus repositórios, seja por meio das APIs REST ou GraphQL, ou por meio de um cliente Git.

Usuários máquina

Se o servidor tiver de acessar vários repositórios, você poderá criar uma nova conta em your GitHub Enterprise Server instance e anexar uma chave SSH que será usada exclusivamente para automatização. Como essa conta em your GitHub Enterprise Server instance não será usada por uma pessoa, ela é chamada denominada usuário de máquina. É possível adicionar o usuário máquina como colaborador em um repositório pessoal (concedendo acesso de leitura e gravação), como colaborador externo em um repositório da organização (concedendo leitura, acesso gravação, ou administrador) ou como uma equipe, com acesso aos repositórios que precisa automatizar (concedendo as permissões da equipe).

Prós

  • Qualquer pessoa com acesso ao repositório e servidor é capaz de implantar o projeto.
  • Nenhum usuário (humano) precisa alterar suas configurações de SSH locais.
  • Não são necessárias várias chaves; o adequado é uma por servidor.

Contras

  • Apenas organizações podem restringir os usuários máquina para acesso somente leitura. Os repositórios pessoais sempre concedem aos colaboradores acesso de leitura/gravação.
  • Chaves dos usuário máquina, como chaves de implantação, geralmente não são protegidas por senha.

Configuração

  1. Execute o procedimento ssh-keygen no seu servidor e anexe a chave pública �  conta do usuário máquina.
  2. Dê acesso �  conta de usuário máquina aos repositórios que deseja automatizar. Você pode fazer isso adicionando a conta como colaborador, como colaborador externo ou como uma equipe em uma organização.

Leia mais