Chaves de deploy, SSH e tokens no GitHub: qual credencial usar para implantar
Publicado em 2026-10-26 por frfrand
Acesso seguro de servidores a repositórios GitHub sem compartilhar contas
Para que um VPS faça o download de um repositório privado, você não deve copiar sua senha pessoal para o servidor. O GitHub oferece diferentes mecanismos de acesso: uma deploy key, um token ou um GitHub App. A melhor opção depende do escopo e da automação.
A ideia é usá-lo para resolver um problema de verdade, não memorizar comandos porque ficam bem em uma captura. Vamos ao essencial, um exemplo de trabalho e os erros que mais convém evitar.
O que fazem Deploy keys, SSH e tokens e quando servem
Uma deploy key SSH geralmente é associada a um repositório específico e pode ser configurada como somente leitura. Os tokens pessoais têm permissões e vencimentos configuráveis, mas convém evitar escopos desnecessários. Os GitHub Apps podem emitir credenciais de curta duração e granularidade mais adequada a integrações grandes.
Se você está aprendendo, teste primeiro em um repositório ou ambiente de teste. Se administra produção, documente o estado antes de executar qualquer coisa que altere arquivos, histórico ou dados. Isso permite entender o que mudou e recuperar-se se errar.
Exemplo para copiar e entender
# En el VPS, crear una clave específica de despliegue
ssh-keygen -t ed25519 -f ~/.ssh/deploy_proyecto -C 'deploy-proyecto'
# Ver sólo la CLAVE PUBLICA
cat ~/.ssh/deploy_proyecto.pub
# Verificar GitHub al conectar
ssh -T git@github.comNão copie a ordem final sem olhar o estado prévio. Os nomes de branches, host, usuário ou caminhos são exemplos; substitua-os pelos do seu projeto. Alguns comandos modificam arquivos ou fazem requisições que podem gravar dados.
Como eu usaria passo a passo
- Passo 1. Crie uma identidade separada para o deploy, não reutilize a chave SSH pessoal.
- Passo 2. Adicione apenas a chave pública ao repositório como deploy key de leitura, quando o fluxo permitir.
- Passo 3. Verifique a impressão digital do host do GitHub com informações oficiais antes de aceitar o primeiro acesso.
- Passo 4. Guarde a chave privada com permissões rígidas e não a copie dentro do Git.
- Passo 5. Documente como revogar o acesso quando mudar a equipe ou o servidor.
Pare após cada passo e comprove o resultado. Se algo falhar, anote a mensagem exata antes de mudar de estratégia. Pular entre cinco soluções aleatórias costuma dificultar encontrar a causa real.
Um caso que poderia acontecer com clientes
Uma agência administra repositórios privados de diferentes clientes. Com credenciais separadas por projeto, um servidor comprometido não precisa ter leitura sobre todos os repositórios da agência.
O objetivo não é que «funcione uma vez», mas que você possa explicar como repete sem comprometer outra aplicação. Se houver dados ou credenciais de clientes, trabalhe com testes separados e acessos mínimos.
O erro que mais vejo
Nunca cole uma chave privada em um incidente nem a passe para uma IA ou colaborador sem controles. As credenciais também podem ficar expostas em logs de CI; evite comandos que imprimam segredos.
Uma regra simples: se você não puder explicar o que o comando fará no seu código ou servidor, consulte primeiro a ajuda oficial. Assim, você evita confundir uma solução rápida com um novo problema.
Onde entra o ArduMaker?
No ArduMaker, as integrações Git do implantação devem usar permissões mínimas por projeto e Empresa. Escolha chaves separadas para evitar que o VPS de um cliente acesse o código de outro.
Por exemplo, você pode implantar a partir de um repositório Git para um VPS, associar um domínio HTTPS e administrar serviços e bancos de dados no mesmo ambiente. O painel reduz tarefas repetitivas de infraestrutura, mas não substitui o Git, os testes nem a revisão de permissões do projeto.
Perguntas rápidas antes de aplicá-lo
Isso altera a produção? Depende de onde você executa a ação. Teste localmente primeiro, identifique o commit ou serviço afetado e prepare um plano de recuperação.
Como comprovar que deu certo? Não fique apenas com a ausência de mensagens de erro: revise o status, execute um teste funcional e verifique os logs ou o histórico correspondente.
Vale a pena automatizá-lo? Se for repetível e tiver resultados verificáveis, sim. Mas a automação deve falhar de forma clara e não esconder erros ou credenciais.
Para ampliar
Resumo: a ferramenta útil não é a que tem mais opções, mas sim a que permite entender o que mudou, comprovar isso e continuar trabalhando sem surpresas.