Chave SSH vazou no chat? Como dar e tirar acesso à VM sem chave compartilhada

Em março, a chave privada deploy_id_rsa foi colada no chat do time "só para o Lucas acessar hoje". Em setembro, o Lucas saiu da empresa. Em outubro, alguém perguntou: quem ainda consegue entrar na VM da loja? Ninguém sabia. A mesma chave estava no chat, num ticket de suporte, no notebook de três pessoas e, descobriram depois, num repositório antigo.

A resposta curta: chave privada não se compartilha; cada pessoa gera a sua e entrega só a pública. No Google Cloud, a pública vai para o metadado da instância ou, melhor ainda, o acesso passa a ser controlado pelo OS Login, ligado à conta de cada pessoa no IAM. Quem sai perde o acesso no mesmo dia. Se uma chave privada vazou, retire a pública correspondente de todo lugar antes de qualquer outra coisa.

Por que a chave compartilhada vira acesso eterno

SSH com chave funciona assim: a VM guarda uma lista de chaves públicas autorizadas e aceita quem provar que tem a privada correspondente. Ela não sabe quem é a pessoa, só que a chave confere. Se cinco pessoas usam a mesma privada, a VM vê um usuário só, e o log não diz quem entrou.

Pior: tirar o acesso de uma dessas pessoas exige trocar a chave de todas. Como isso dá trabalho, ninguém faz, e a chave segue valendo para quem saiu, para quem tem o histórico do chat e para quem achar o arquivo no repositório. Texto colado em ticket ou mensagem fica guardado em backup, em notificação de e-mail, em exportação de conversa. Você não controla mais onde ele está.

A configuração inicial de entrar na VM sem senha está em chave SSH na VM. Este guia cuida do que vem depois: equipe que muda, chave que vaza.

Passo 1: descubra quem entra hoje

No Compute Engine, chaves podem estar em três lugares: no metadado do projeto (valem para todas as VMs que não as bloqueiam), no metadado da instância e direto nos arquivos authorized_keys da máquina. Confira os três:

gcloud compute project-info describe
gcloud compute instances describe vm-loja --zone southamerica-east1-a

Procure o item ssh-keys na saída de cada comando. Depois, dentro da VM, liste a impressão digital de toda chave autorizada:

sudo sh -c 'for f in /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys; do
  [ -f "$f" ] || continue
  echo "== $f"
  ssh-keygen -lf "$f"
done'

Na VM da loja, a lista mostrou sete chaves para quatro pessoas ativas. Duas não tinham comentário nenhum. Uma era a deploy_id_rsa. Chave sem dono identificado é chave a ser removida.

Passo 2: uma chave por pessoa, com nome

1. Cada pessoa gera a própria chave, no próprio computador, com senha (passphrase).
2. O comentário identifica a pessoa e a data, para o inventário futuro ser legível.
3. Só o arquivo .pub sai do computador. A privada nunca vai para chat, e-mail, ticket ou repositório.

ssh-keygen -t ed25519 -C "ana.souza 2026-10"

Com ssh-agent, a senha da chave é digitada uma vez por sessão, então ela não atrapalha o dia a dia. E uma privada roubada do notebook, sem a senha, não serve de nada.

Passo 3a: lista versionada no metadado da instância

Se você ainda usa metadado, mantenha a lista de chaves públicas num arquivo do repositório de infraestrutura. Chave pública não é segredo, e o histórico do Git vira o registro de quem ganhou e perdeu acesso, com revisão em pull request.

# chaves-vm-loja.txt  (formato: usuario:chave comentario)
ana:ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExemploAna ana.souza 2026-10
bruno:ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExemploBruno bruno.lima 2026-10

gcloud compute instances add-metadata vm-loja \
  --zone southamerica-east1-a \
  --metadata-from-file ssh-keys=chaves-vm-loja.txt

gcloud compute instances add-metadata vm-loja \
  --zone southamerica-east1-a \
  --metadata block-project-ssh-keys=TRUE

O valor de ssh-keys é substituído inteiro, não somado. Isso é ótimo para este método: o arquivo é a verdade, e quem não está nele perde o acesso. O segundo comando impede que chaves esquecidas no metadado do projeto continuem valendo nesta VM. Lembre que chaves colocadas à mão no authorized_keys não são geridas pelo metadado: confira e remova as que sobraram do passo 1.

Passo 3b: OS Login, o acesso pela conta da pessoa

Com o OS Login, a VM deixa de aceitar as chaves do metadado e passa a perguntar ao IAM se aquela conta tem permissão. O acesso segue a conta corporativa: quem é desligado no Google Workspace ou removido do IAM perde a entrada sem que ninguém precise lembrar da VM.

gcloud compute instances add-metadata vm-loja \
  --zone southamerica-east1-a \
  --metadata enable-oslogin=TRUE

gcloud projects add-iam-policy-binding projeto-loja \
  --member="user:ana.souza@empresa.com.br" \
  --role="roles/compute.osLogin"

O papel roles/compute.osLogin dá acesso sem sudo. Quem administra recebe roles/compute.osAdminLogin. Para tirar, use remove-iam-policy-binding com os mesmos parâmetros. Teste com uma conta de teste antes de aplicar em produção, para não se trancar fora da máquina.

E certificados de curta duração?

Fora do Google Cloud, ou em frotas grandes, o OpenSSH aceita certificados assinados por uma autoridade sua. A VM confia na autoridade (TrustedUserCAKeys no sshd_config) e você assina a chave de cada pessoa com validade curta, como ssh-keygen -s ca_usuarios -I ana -n ana -V +8h id_ed25519.pub. Passadas as oito horas, o certificado expira sozinho.

No dia em que alguém sai

1. Remova a linha da pessoa do arquivo de chaves e aplique, ou tire o papel no IAM.
2. Confira no authorized_keys da VM que a impressão digital dela sumiu.
3. Se ela conhecia alguma senha ou token que a máquina usa, troque também.

Faça no mesmo dia, como parte do desligamento, não "quando der". A pergunta do fechamento deste guia só tem resposta boa se esse passo for rotina.

Se uma chave privada vazou

1. Retire a pública correspondente do metadado do projeto, da instância e de todo authorized_keys. É isso que corta o acesso.
2. Confira os acessos recentes: journalctl -u ssh no Debian e Ubuntu (o serviço se chama sshd em outras distribuições) ou /var/log/auth.log.
3. Se houve entrada suspeita, trate a máquina como comprometida: troque os segredos que ela guarda e avalie recriá-la.
4. Só depois gere a nova chave para quem precisa e, se a privada foi para um repositório, limpe o histórico.

A ordem importa pelo mesmo motivo de qualquer segredo em Git: apagar o arquivo não desfaz cópias. Veja segredo no Git: troque a chave antes de limpar o histórico e, para trocas sem queda, rotação que tem dois passos.

Erros comuns

• Uma chave da equipe: o log não diz quem entrou, e tirar o acesso de uma pessoa exige trocar o de todas.
• Colar a privada em chat ou ticket: a chave passa a existir em backups e exportações que você não controla.
• Chave sem comentário: no próximo inventário ninguém sabe de quem é, e ela fica "por segurança".
• Esquecer o metadado do projeto: a chave removida da instância continua valendo pelo projeto.
• Remover do metadado e esquecer o authorized_keys: a chave colocada à mão continua abrindo a porta.
• Gerar chave nova antes de retirar a vazada: por um tempo, as duas abrem a VM.

Checklist

• Cada pessoa tem a própria chave, com senha e comentário com nome e data.
• Nenhuma chave privada aparece em repositório, chat ou ticket.
• A lista de chaves públicas está versionada ou o acesso é pelo OS Login.
• A VM bloqueia chaves do projeto se a lista da instância é a referência.
• O authorized_keys só tem impressões digitais de pessoas ativas.
• O desligamento inclui retirar o acesso SSH no mesmo dia.
• Existe um roteiro escrito para chave vazada, começando por retirar a pública.

Rode o laço do ssh-keygen -lf na sua VM agora e compare com a lista de pessoas do time: alguém que saiu no mês passado ainda entraria?