Uma chave SSH por pessoa: o detalhe que muda tudo quando você é uma equipe

Publicado em 2026-09-12 por frfrand

Por qué compartir una clave privada arruina el modelo entero, cómo se agregan y quitan claves sin tocar a nadie más, y qué hacer el día que alguien pierde la laptop.

Há um atalho muito comum em equipes pequenas: gera-se uma chave SSH "do projeto", guarda-se no gerenciador de senhas compartilhado e todo mundo usa.

Funciona. E desmonta quase tudo de bom que o SSH tem.

Por que a chave compartida quebra o modelo

O design do SSH se apoia em uma premissa: a chave privada identifica alguém e não sai da máquina dela. Se a chave circula, essa premissa desaparece e com ela três propriedades:

Já não identifica. O log diz que entrou "deploy". Você não sabe quem. Depois de um incidente, a pergunta "quem executou isso?" não tem resposta.

Já não se pode revogar de um em um. Tirar o acesso de uma pessoa implica gerar uma chave nova e distribuí-la a todos os outros. Como isso incomoda todo mundo, é adiado. E é assim que alguém que saiu há oito meses ainda consegue entrar.

Você não sabe quantas cópias existem. Uma chave privada que passou por um gerenciador compartilhado está em cada laptop onde alguém a baixou, e em qualquer backup desses laptops.

O que muita gente não sabe

A razão pela qual se compartilha costuma ser uma ideia equivocada: que colocar várias chaves é complicado, ou que ter muitas chaves públicas em um servidor o enfraquece.

Nenhuma das duas é verdadeira.

O arquivo ~/.ssh/authorized_keys é uma lista. Uma chave pública por linha. Você pode ter vinte e não acontece nada, porque uma chave pública não permite deduzir a privada. Esse é o ponto inteiro da criptografia assimétrica.

# ~/.ssh/authorized_keys ssh-ed25519 AAAAC3Nza... ana@laptop ssh-ed25519 AAAAC3Nza... bruno@laptop ssh-ed25519 AAAAC3Nza... ci-deploy

O comentário final de cada linha (ana@laptop) não tem função técnica e é justamente o que o torna mantível: é o que permite saber, dentro de seis meses, de quem é cada uma.

Como adicionar e remover

Adicionar, a partir da máquina da pessoa:

ssh-copy-id ana@miservidor.com

Remover: excluir a linha dela do arquivo. É só isso. Ninguém mais fica sabendo, ninguém mais precisa mudar nada.

Compare isso com o outro modelo, onde tirar alguém envolve coordenar uma mudança com toda a equipe. A diferença não está em como o acesso é concedido: está em quanto custa removê-lo.

As chaves das máquinas também são pessoas

Um servidor de integração contínua que faz deploy precisa de sua própria chave, diferente das das pessoas. Dois motivos:

• Se o sistema de CI for comprometido, você revoga essa chave sem afetar ninguém.
• Essa chave pode ter permissões mais restritas. Com a opção command no authorized_keys, é possível forçar que essa chave execute apenas um script específico, sem shell interativa:

command="/usr/local/bin/deploy.sh",no-pty ssh-ed25519 AAAA...

É uma das funções mais úteis e menos usadas do SSH.

No dia em que alguém perder o laptop

Com chaves por pessoa, o procedimento é curto: excluir essa linha nos servidores onde ela estava e gerar um par novo.

Com chave compartida, o procedimento é rotacionar a chave do projeto inteiro e coordenar com todos. Que é exatamente por isso que, na prática, não se faz.

Uma recomendação que economiza esse susto: coloque uma senha na chave privada. Se alguém roubar sua máquina, o arquivo sozinho não basta. O agente SSH a guarda enquanto durar sua sessão, então você não precisa digitá-la o tempo todo.

Como fazemos

Na ArduMaker, cada usuário de um VPS tem sua própria chave, carregada pelo painel. Adicionar alguém é somar a chave pública dele; remover é retirá-la. Não há uma credencial compartilhada para rotacionar, e cada comando executado pela plataforma fica associado a quem o lançou.

É a mesma ideia de sempre: o que define um bom modelo de acesso não é o quão fácil é conceder permissão, mas o quão rápido se pode removê-la.