Chave SSH na VM: entre sem senha e sem deixar a chave privada no projeto

A VM sobe e o tutorial diz "adicione sua chave". Alguém cola a chave errada, a privada, no metadado, num arquivo do repositório ou numa variável de CI sem proteção. A partir daí, quem tem acesso ao repositório entra na máquina. A resposta curta: o par de chaves nasce no seu computador. Só a chave pública, a linha que termina em .pub, vai para a VM, no ~/.ssh/authorized_keys ou no campo de chaves do provedor. A privada nunca sai do seu usuário, tem senha e é uma por pessoa.

SSH com chave é mais seguro que senha. SSH com a chave privada publicada é uma porta aberta com o seu nome na fechadura.

Como o par de chaves funciona

A chave privada assina. A pública confere a assinatura. Quando você conecta, o servidor manda um desafio, o seu cliente SSH assina com a privada e o servidor verifica com a pública que está no authorized_keys. A privada não trafega pela rede em nenhum momento. Por isso a pública pode ficar em qualquer servidor, num painel de provedor ou até num repositório: ela só abre a porta para quem tem a privada correspondente.

A consequência é direta. Quem copia a sua chave privada vira você para todos os servidores onde a sua pública está autorizada. Não existe "revogar só essa cópia". Você precisa tirar a pública de todos os lugares e gerar um par novo.

Por isso também a chave compartilhada "da equipe" é um problema. Se cinco pessoas usam o mesmo par e uma sai da empresa, não há como tirar o acesso só dela. Você troca a chave de todo mundo, ou deixa a porta aberta.

Como gerar a chave e instalar na VM

1. Gere o par na sua máquina, com o algoritmo Ed25519 e uma senha.
2. Copie só o conteúdo do arquivo .pub para a VM.
3. Confira as permissões da pasta ~/.ssh no servidor.
4. Teste o login por chave numa sessão nova, mantendo a atual aberta.
5. Só depois desligue o login por senha.

# na sua máquina
ssh-keygen -t ed25519 -C "marina@notebook"
# aceite o caminho padrão (~/.ssh/id_ed25519) e defina uma senha

# copie a pública para a VM (Linux e macOS)
ssh-copy-id -i ~/.ssh/id_ed25519.pub marina@203.0.113.10

# confira a impressão digital da chave
ssh-keygen -lf ~/.ssh/id_ed25519.pub

A senha da chave protege o arquivo se o notebook for roubado. Para não digitá-la a cada conexão, use o agente: ssh-add ~/.ssh/id_ed25519 carrega a chave na memória durante a sessão. No Windows, o OpenSSH já vem instalado, e o ssh-keygen funciona igual no PowerShell. Se o ssh-copy-id não estiver disponível, copie a linha do .pub e acrescente ao authorized_keys no servidor:

# no servidor, logado como o usuário de destino
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys   # cole a linha da chave pública, uma por linha
chmod 600 ~/.ssh/authorized_keys

Se as permissões estiverem largas demais, o servidor SSH ignora o arquivo e volta a pedir senha, sem explicar o motivo para o cliente. O motivo aparece no log do servidor.

Em VMs de nuvem

Provedores como Google Cloud, AWS e Azure deixam você cadastrar a chave pública no painel ou no metadado da VM, e um agente na máquina grava a linha no authorized_keys do usuário. No Google Cloud, o formato no metadado inclui o nome do usuário antes da chave, e o próprio gcloud compute ssh gera e cadastra um par para você. Para equipes, o Google recomenda o OS Login, que associa o acesso à conta de cada pessoa e permite revogar pelo controle de acesso, sem editar arquivo em cada máquina. Em qualquer provedor, o campo é para a chave pública. Se o texto que você vai colar começa com -----BEGIN OPENSSH PRIVATE KEY-----, pare.

Como desligar o login por senha sem se trancar fora

Com a chave funcionando, a senha vira só uma porta a mais para ataques de força bruta. Desligue, mas com uma sessão aberta durante todo o processo:

# /etc/ssh/sshd_config.d/10-seguranca.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'
sudo systemctl reload ssh   # no RHEL e derivados: sudo systemctl reload sshd

O sshd -t valida a sintaxe. O sshd -T mostra a configuração efetiva, e esse passo importa: no sshd_config, vale o primeiro valor encontrado para cada opção, e algumas imagens de nuvem trazem um arquivo em sshd_config.d que liga a senha. Se o seu arquivo for lido depois, ele não tem efeito. Nomear o arquivo com um número baixo, como 10-, faz ele ser lido antes, desde que o Include do diretório esteja no topo do sshd_config, como no Ubuntu e no Debian. Em OpenSSH anterior à versão 8.7, a opção KbdInteractiveAuthentication se chama ChallengeResponseAuthentication. Antes de fechar a sessão atual, abra outro terminal e confirme que o login por chave funciona.

Como tirar o acesso de alguém

Quando uma pessoa sai da equipe, apague a linha da chave pública dela do authorized_keys de cada servidor, ou remova o acesso no OS Login ou no gerenciador equivalente. Remover a chave não derruba sessões que já estão abertas. Confira com who ou sudo loginctl list-sessions e encerre a sessão dela com sudo loginctl terminate-session seguido do número.

Se uma chave privada vazou, procure no repositório, inclusive no histórico:

git grep -n "BEGIN OPENSSH PRIVATE KEY"
git log -p --all -S "BEGIN OPENSSH PRIVATE KEY"

Achou? Primeiro gere um par novo e tire a pública antiga de todos os servidores. Só depois limpe o histórico. A ordem importa, e o motivo está em segredo no Git se troca antes de limpar.

Erros comuns

• Colar a chave privada no metadado ou no repositório. Qualquer pessoa com acesso ao painel ou ao Git entra no servidor como você.
• Uma chave compartilhada pela equipe. Quando alguém sai, não dá para revogar só aquela pessoa, e ninguém sabe quem fez o quê nos logs.
• Chave privada sem senha. Um notebook roubado ou um backup vazado dá acesso imediato aos servidores.
• Desligar a senha e fechar a sessão antes de testar a chave. Você fica trancado para fora e depende do console do provedor.
• Login por senha de root deixado "para emergência". Ele é o alvo principal das tentativas automáticas que todo IP público recebe.
• Permissão aberta em ~/.ssh. O servidor ignora o authorized_keys, volta a pedir senha e você perde tempo procurando o erro no lugar errado.

Checklist

• Cada pessoa tem o próprio par de chaves, com senha.
• Só arquivos .pub foram copiados para servidores e painéis.
• ~/.ssh tem permissão 700 e authorized_keys tem 600.
• sshd -T mostra passwordauthentication no e permitrootlogin no.
• A busca por "BEGIN OPENSSH PRIVATE KEY" no repositório e no histórico não retorna nada.
• Existe uma lista de quem tem chave autorizada em cada VM.
• A saída de alguém da equipe inclui remover a chave e encerrar sessões abertas.

Abra o ~/.ssh/authorized_keys da sua VM agora. Você sabe dizer de quem é cada linha que está lá?