Usar chaves SSH em vez de senha

Senha é um segredo curto que pode ser adivinhado. Chave é um segredo de centenas de bits que nunca sai da sua máquina. Essa é a diferença inteira.

Um servidor com a porta 22 exposta recebe tentativas de login automatizadas em minutos. Elas testam root com senhas de dicionário, sem parar, de milhares de origens diferentes. Contra senha, a única defesa é que a sua seja boa o bastante e permaneça assim. Contra chave, o ataque simplesmente não tem o que testar: sem a chave privada, o cliente não consegue completar o desafio criptográfico, e nenhuma quantidade de tentativas ajuda.

Como a autenticação por chave funciona

Você gera um par: uma chave privada, que fica no seu computador, e uma pública, que você instala no servidor. Na conexão, o servidor manda um desafio; o cliente responde assinando esse desafio com a privada. O servidor verifica a assinatura usando a pública e libera a sessão.

A privada nunca é transmitida. Isso implica duas coisas práticas:

• A chave pública pode ser copiada, publicada, versionada. Ela não é segredo.
• A chave privada é o acesso em si. Quem tiver o arquivo entra no servidor, a menos que ela esteja protegida por passphrase.

Gerar o par

No seu computador — não no servidor. A chave privada deve nascer e morrer na máquina que você usa.

ssh-keygen -t ed25519 -C "notebook-crystian"

Sobre cada parte:

• -t ed25519 escolhe o algoritmo. Ed25519 é o padrão atual: chaves curtas, verificação rápida, sem os parâmetros frágeis do RSA. Use RSA de 4096 bits só se precisar falar com um sistema antigo que não suporte Ed25519: ssh-keygen -t rsa -b 4096.
• -C é apenas um comentário. Coloque algo que identifique a máquina de origem, não a pessoa. Quando você tiver quatro chaves em authorized_keys e precisar revogar a do notebook roubado, esse comentário é o que diz qual linha apagar.

Aceite o caminho sugerido (~/.ssh/id_ed25519) ou dê um nome específico se você mantém chaves separadas por contexto. Quando pedir a passphrase, defina uma. Ela cifra a chave privada em disco: se o notebook for perdido, o arquivo sozinho não serve. O incômodo de digitar a passphrase é resolvido pelo agente:

ssh-add ~/.ssh/id_ed25519

No macOS, ssh-add --apple-use-keychain guarda a passphrase no Keychain. No Linux, o agente da sessão desktop normalmente já cuida disso. No Windows, o serviço ssh-agent precisa estar habilitado.

Ficam dois arquivos: id_ed25519 (privada) e id_ed25519.pub (pública). Nunca copie o primeiro para lugar nenhum.

Instalar a chave pública no servidor

Se você ainda tem login por senha funcionando, o caminho mais curto:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

O comando acrescenta a linha em ~/.ssh/authorized_keys do usuário remoto e ajusta as permissões. Ele não substitui o que já existe — chaves anteriores continuam válidas.

Se o login por senha já está desligado, ou o servidor foi criado sem senha inicial, use o console no browser para entrar na máquina e adicione a linha manualmente:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
printf '%s\n' 'ssh-ed25519 AAAAC3Nza...cQ4 notebook-crystian' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

As permissões não são detalhe cosmético. O sshd ignora authorized_keys se o arquivo ou o diretório forem graváveis por outros usuários — e falha silenciosamente, devolvendo Permission denied (publickey) sem explicar o motivo. Se a chave "não funciona" e você tem certeza de que copiou certo, comece por aqui.

Também confira o dono dos arquivos. Um authorized_keys criado com sudo dentro do diretório de outro usuário pertence ao root e é descartado.

Testar antes de desligar a senha

Este é o passo que separa uma mudança tranquila de um servidor inacessível. Não altere a configuração do SSH antes de confirmar que a chave entra.

Mantenha a sessão atual aberta e, em outro terminal:

ssh -i ~/.ssh/id_ed25519 root@203.0.113.10

Se pedir senha, a chave não está sendo aceita. Diagnostique com verbosidade antes de seguir:

ssh -vvv -i ~/.ssh/id_ed25519 root@203.0.113.10

Procure a linha Offering public key. Se ela aparece e a autenticação falha depois, o problema está no servidor — permissão, dono ou conteúdo do authorized_keys. Se ela não aparece, o cliente não está usando a chave que você pensa. A tabela de mensagens de erro em Acessar sua VPS por SSH cobre os outros casos.

Desligar a autenticação por senha

Só depois do teste acima. Em /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

KbdInteractiveAuthentication no importa: em várias distribuições ele é o caminho pelo qual a senha continua sendo aceita mesmo com PasswordAuthentication no. Desligar um e esquecer o outro é o erro clássico de quem acha que fechou e não fechou.

PermitRootLogin prohibit-password mantém o acesso root por chave e nega por senha. Se você criou um usuário comum com sudo, PermitRootLogin no é melhor ainda.

Distribuições recentes carregam arquivos de /etc/ssh/sshd_config.d/, e essas diretivas podem ser sobrescritas por lá. Confirme o que está em vigor de verdade:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin|pubkeyauth'

Valide a sintaxe e recarregue sem cortar sessões:

sudo sshd -t && sudo systemctl reload sshd

O sshd -t recusa um arquivo inválido em vez de derrubar o serviço. O reload preserva as conexões estabelecidas — inclusive a sua. Abra uma terceira sessão para confirmar que ainda entra. Se falhar, você tem a original para desfazer.

Se a mudança faz parte de um endurecimento maior da máquina, tire um snapshot antes. A captura é instantânea, sem downtime, e transforma um erro de configuração em um retorno de poucos minutos.

Rotina depois disso

Trate authorized_keys como lista de acesso, e revise de vez em quando. Uma chave lá é uma pessoa ou uma máquina com entrada permanente.

ssh-keygen -lf ~/.ssh/authorized_keys

Revogar acesso é apagar a linha correspondente — imediato, sem trocar senha de ninguém. Para automação (CI, backup, deploy), gere uma chave separada por sistema, sem passphrase se o processo precisar rodar sem interação, e restrinja o que ela pode fazer com as opções de prefixo em authorized_keys, como command= e restrict.

Com a senha fora do caminho, manter a 22 acessível deixa de ser o risco principal, e você pode priorizar o resto das regras de firewall — bancos de dados fechados, saída controlada — em vez de brigar com força bruta.