como gerenciar chaves ssh corretamente

Como funcionam as chaves SSH

Uma chave SSH é um par de arquivos: uma chave privada que permanece no seu dispositivo e uma chave pública que você copia para cada servidor onde deseja fazer login. Quando você se conecta, o servidor usa a chave pública para enviar um desafio que apenas a chave privada correspondente pode responder. A chave privada nunca sai do seu dispositivo, portanto, nenhum segredo trafega pela rede e um servidor comprometido não terá nada útil para roubar. É por isso que chaves são superiores a senhas. Gerenciar chaves SSH de forma eficiente depende de quatro hábitos: uma chave por dispositivo, as permissões de arquivo exigidas pelo sshd, um arquivo ~/.ssh/config para evitar a digitação de opções e saber como remover uma chave no dia em que um laptop for perdido.

Este guia aborda cada hábito no Ubuntu 24.04, embora quase tudo aqui se aplique a qualquer servidor Linux e qualquer versão recente do OpenSSH.

Um ponto de vocabulário antes de começar, para evitar erros reais. A chave pública não é secreta. Você pode colá-la em um ticket, enviá-la por e-mail ou publicá-la, e ninguém conseguirá fazer login com ela. A chave privada é o segredo. Qualquer pessoa que copiar esse arquivo, e saiba sua passphrase (caso possua uma), será você para os seus servidores.

Criar uma chave: ed25519 é o padrão correto

No seu próprio computador, não no servidor, execute:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 define o tipo de chave. Ed25519 é o padrão moderno: as chaves são curtas, rápidas e suportadas por todas as versões do OpenSSH desde 2014. Use ssh-keygen -t rsa -b 4096 apenas se precisar se conectar a um dispositivo antigo que não suporte ed25519. -C "laptop" define um comentário. O comentário não possui função criptográfica, mas é como você identificará esta chave no arquivo authorized_keys de um servidor daqui a dois anos; portanto, use o nome do dispositivo onde a chave reside.

ssh-keygen pergunta onde salvar a chave. Aceite o padrão, ~/.ssh/id_ed25519. Em seguida, será solicitada uma passphrase. Defina uma; a seção sobre passphrase abaixo explica por que ela não impacta seu uso diário. Você terá dois arquivos: ~/.ssh/id_ed25519 é a chave privada e ~/.ssh/id_ed25519.pub é a chave pública. Veja a metade pública:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

É apenas uma linha: o tipo de chave, o conteúdo da chave e o seu comentário. Essa linha é o que será enviado para os seus servidores.

Uma chave por dispositivo, não uma por servidor

A primeira pergunta de todos: eu preciso de uma chave nova para cada servidor? Não. Crie uma chave para cada dispositivo que você utiliza para digitar e adicione essa chave pública em todos os servidores que o dispositivo precisa acessar. A chave identifica o dispositivo. O arquivo authorized_keys em cada servidor é a lista de dispositivos permitidos.

Este é o modelo escalável; as alternativas falham de formas previsíveis. Uma chave por servidor significa que um laptop com vinte servidores carregará vinte chaves privadas, e você perderá o controle de qual é qual. Uma chave compartilhada por todos os seus dispositivos é pior: se o laptop for roubado, você não pode revogar o acesso do laptop sem bloquear também o seu desktop, pois ambos possuem a mesma chave privada. Assim, você teria que substituir a chave em todos os lugares e redistribuí-la para todos os dispositivos de uma só vez.

Com uma chave por dispositivo, o laptop perdido custa apenas uma linha por servidor: delete a linha do laptop no arquivo authorized_keys e todos os outros dispositivos continuarão funcionando. O comentário que você define com -C é o que torna essa linha fácil de encontrar.

A regra por trás do modelo: uma chave privada é criada em um dispositivo e morre com esse dispositivo. Nunca copie uma chave privada para uma segunda máquina e nunca faça upload de uma para um servidor. Quando um novo dispositivo precisar de acesso, gere uma nova chave nele.

Coloque a chave pública no servidor

O caminho mais fácil é o ssh-copy-id, que vem com o OpenSSH:

ssh-copy-id matt@10.0.0.10

Ele faz o login com o método que ainda estiver funcionando, geralmente uma senha, anexa sua chave pública ao ~/.ssh/authorized_keys no servidor e cria o diretório e o arquivo com as permissões corretas caso não existam. Teste abrindo uma nova sessão SSH: o servidor deve permitir o acesso sem solicitar a senha da conta. Se sua chave tiver uma passphrase, sua própria máquina pode solicitá-la; esse prompt é local e não é a senha do servidor.

Quando o login por senha já está desativado, o ssh-copy-id não consegue entrar, então você deve adicionar a linha manualmente. Faça login através de uma sessão que ainda funcione, ou pelo console web do seu provedor, e execute isto no servidor:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Cole sua chave pública real dentro das aspas, a linha completa vinda do id_ed25519.pub. O authorized_keys possui uma chave pública por linha, e esse é o banco de dados de acesso completo: adicionar um dispositivo significa anexar uma linha, e revogar um dispositivo significa deletar uma linha. Em um servidor novo, este passo faz parte do primeiros 10 minutos em um novo VPS, logo antes de desativar o login por senha.

Permissões que impedem o login por chave

Esta é a causa mais comum de falhas no login por chave, e o erro ocorre de forma silenciosa no lado do cliente. O sshd roda com StrictModes yes por padrão no Ubuntu 24.04, o que significa que ele recusa o uso de um arquivo authorized_keys que outros usuários possam editar. Se o arquivo, o diretório ~/.ssh, ou seu diretório home permitirem escrita por qualquer pessoa que não seja você, o sshd ignora sua chave e solicita uma senha, sem exibir explicações no cliente. (O OpenSSH do Ubuntu tolera apenas um caso específico: um arquivo com permissão de grupo para o seu próprio grupo privado, do qual ninguém mais faz parte. Não dependa disso; mantenha os modos abaixo.) O motivo só aparece no log do servidor:

sudo grep 'Authentication refused' /var/log/auth.log

Em uma imagem mínima sem rsyslog, não há auth.log; a mesma linha está no journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

A correção consiste em duas alterações de permissão e uma verificação de proprietário, executadas no servidor pelo usuário afetado:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

A regra para memorizar: 700 no diretório .ssh, 600 em tudo o que estiver dentro dele. As mesmas regras se aplicam ao seu próprio computador, pois o cliente também realiza a verificação. Uma chave privada legível por outros usuários faz com que o ssh recuse a chave imediatamente, e desta vez o erro é exibido:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 resolve o problema.

~/.ssh/config: pare de digitar opções

Um arquivo ~/.ssh/config no seu próprio computador atribui um nome curto para cada servidor e memoriza as opções que você costuma digitar. Crie o arquivo com permissões 600 e adicione um bloco Host para cada servidor:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Agora ssh web1 substitui ssh -p 22 matt@10.0.0.10, e o mesmo nome curto funciona em scp, rsync e git, pois todos eles leem este arquivo. HostName é o endereço real, User evita que você digite o nome do usuário, e IdentityFile define qual chave será enviada.

IdentitiesOnly yes merece uma explicação, pois corrige uma falha confusa. Quando o seu agent possui várias chaves, o client as oferece uma por uma, e o servidor conta cada oferta como uma tentativa falha. Com muitas chaves carregadas, você recebe Received disconnect: Too many authentication failures antes que a chave correta seja testada. IdentitiesOnly yes faz com que o client ofereça apenas a chave especificada em IdentityFile, evitando que a falha ocorra.

Passphrases e ssh-agent

Uma passphrase criptografa o arquivo da chave privada no disco. Sem ela, qualquer pessoa que copiar o arquivo pode usá-lo imediatamente; com ela, o arquivo roubado é inútil até que a passphrase seja descoberta. Para uma chave em um laptop, esse é exatamente o nível de proteção desejado, pois laptops são roubados e backups de laptops vazam.

A razão pela qual uma passphrase não tem custo prático é ssh-agent. O agent mantém sua chave descriptografada na memória, então você digita a passphrase apenas uma vez por sessão de login e todas as conexões subsequentes são instantâneas. A maioria das distribuições Linux desktop e macOS já executa um agent para você. Carregue sua chave nele com:

ssh-add ~/.ssh/id_ed25519

ssh-add -l lista as chaves que o agent possui no momento. Um aviso: o agent forwarding (ssh -A) permite que o servidor remoto use seu agent para autenticação subsequente enquanto você estiver conectado; portanto, habilite-o apenas para servidores em que você confia totalmente e mantenha-o desativado por padrão.

Rotação e revogação: o exercício do laptop perdido

Revogar uma chave SSH comum consiste apenas em remover a linha correspondente do arquivo authorized_keys em todos os servidores que a possuem. Não há autoridade de certificação para notificar nem data de expiração para aguardar. Assim que a linha for removida, novos logins com essa chave falharão.

Execute o exercício agora, enquanto não é uma emergência. Escolha um servidor, abra o ~/.ssh/authorized_keys e localize a chave pelo comentário. Delete a linha com um editor ou filtre-a pelo comentário:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Em seguida, confirme no dispositivo que você acabou de revogar que o login agora falha, e em outro dispositivo que o login ainda funciona. Note um detalhe: remover uma chave não encerra sessões que já estão abertas, pois a chave só é verificada no momento do login. Se estiver revogando um dispositivo roubado, verifique também o who no servidor e encerre qualquer sessão desconhecida.

A rotação é a mesma operação em uma ordem diferente: gere uma nova chave no dispositivo, instale-a com o ssh-copy-id, confirme que a nova chave realiza o login e, então, delete a linha antiga. Faça isso quando um dispositivo mudar de dono, quando uma chave puder ter sido exposta ou quando alguém sair da equipe. Fazer isso manualmente em dois servidores é viável; em vinte, é necessário automação, e gerenciar múltiplos servidores Linux mostra como aplicar o mesmo estado authorized_keys em toda uma frota.

O que não fazer

• Não use a mesma chave privada em todos os seus dispositivos. Isso impede a revogação de um único dispositivo roubado sem a necessidade de substituir a chave em todos os outros.

• Não realize o commit de uma chave privada em um repositório git, mesmo que seja privado. Scanners automatizados monitoram repositórios públicos e testam chaves vazadas minutos após o push; além disso, um repositório que se torne público posteriormente expõe todo o seu histórico.

• Não faça upload da chave privada do seu laptop para um servidor para que este servidor acesse outro servidor. Gere uma chave separada no próprio servidor e autorize essa chave apenas onde for estritamente necessário.

• Não cole uma chave privada em chats, e-mails ou tickets. A chave pública, o arquivo .pub, é a única parte que deve ser compartilhada.

Assim que sua chave permitir o login de forma confiável, desative a autenticação por senha. Isso impede que tentativas de força bruta contra seu servidor tenham sucesso. A configuração pronta para isso está em SSH hardening on a VPS.

FAQ

Como as chaves SSH funcionam sem enviar uma senha?

O servidor armazena sua chave pública em ~/.ssh/authorized_keys. No login, o servidor envia um desafio, seu cliente assina o desafio com a chave privada e o servidor verifica a assinatura com a chave pública. A chave privada nunca sai do seu dispositivo, portanto não há nada para interceptar no trânsito e nada reutilizável para ser roubado do servidor. Um servidor comprometido expõe apenas chaves públicas, que não podem ser usadas para realizar login em nenhum outro lugar.

Devo usar a mesma chave SSH para todos os meus servidores?

Usar uma única chave em vários servidores é correto, desde que essa chave permaneça em um único dispositivo. A regra é uma chave por dispositivo, não uma por servidor: a chave pública do seu laptop deve estar em todos os servidores que o laptop precisa acessar, e seu desktop deve ter sua própria chave. Isso simplifica a revogação, pois perder um dispositivo significa remover apenas uma linha identificável de cada servidor, e os outros dispositivos continuam funcionando.

Quais permissões o diretório .ssh e o arquivo authorized_keys devem ter?

Defina 700 em ~/.ssh e 600 em authorized_keys e em cada chave privada, pertencentes ao usuário que as utiliza. O sshd roda com StrictModes yes por padrão; portanto, se um arquivo ou diretório home permitir escrita para qualquer usuário além do seu, o serviço ignorará sua chave silenciosamente. O único rastro será Authentication refused: bad ownership or modes no log de autenticação ou no journal do servidor.

Como eu removo uma chave SSH de um servidor?

Delete a linha da chave em ~/.ssh/authorized_keys na conta para a qual ela foi autorizada. Localize a linha correta pelo comentário, que é o rótulo após o conteúdo da chave. Novos logins com essa chave falharão imediatamente, mas sessões já abertas permanecerão ativas; encerre também qualquer sessão ativa desse dispositivo caso ele tenha sido roubado. Repita o processo em todos os servidores onde a chave foi copiada.

Eu preciso de uma passphrase na minha chave SSH?

Para uma chave em um laptop ou desktop, sim. A passphrase criptografa o arquivo da chave, tornando uma cópia roubada ou vazada inútil por si só. Além disso, ssh-agent significa que você digita a senha uma vez por sessão, em vez de em cada conexão. Chaves usadas por automação não supervisionada em um servidor geralmente não possuem passphrase, pois não há um humano presente para digitá-la; proteja essas chaves restringindo as permissões da conta de destino.