Chave SSH vs Autenticação por Senha - Por Que as Chaves Vencem
O que você vai aprender
- A diferença fundamental entre autenticação por chave SSH e por senha
- Por que as chaves são mais seguras, explicado a partir de como a criptografia funciona
- O fluxo prático: criar, instalar e proteger chaves com
ssh-keygen
Resumo Rápido
- A autenticação por senha envia um segredo ao servidor para ser verificado. A autenticação por chave nunca deixa o segredo (chave privada) sair do cliente.
- A autenticação por chave é estruturalmente resistente a força bruta, reutilização de senhas e vazamentos.
- Servidores de produção padronizam em autenticação por chave + login por senha desativado.
Premissas (ambiente alvo)
- OpenSSH (a implementação SSH em servidores Linux comuns: Ubuntu/Debian/família RHEL)
- Um cliente OpenSSH também (macOS / Linux / WSL / Windows 10+)
Qual é a diferença entre autenticação por chave e por senha?
Conclusão: A autenticação por senha envia um "segredo que você sabe" ao servidor a cada vez para ser verificado. A autenticação por chave prova que você "tem" a chave privada sem colocá-la na rede.
Os dois métodos diferem fundamentalmente em como provam quem você é.
| Aspecto | Autenticação por senha | Autenticação por chave (chave pública) |
|---|---|---|
| O segredo | Uma senha (memorizada) | Uma chave privada (um arquivo) |
| Para onde viaja | Enviada ao servidor por canal criptografado | Nunca sai do cliente |
| O que o servidor guarda | Hash da senha | Sua chave pública (authorized_keys) |
| Principal vetor de ataque | Adivinhação, força bruta, reutilização, phishing | Roubo do arquivo de chave privada |
Uma senha é "uma string na sua cabeça"; uma chave privada é "um arquivo nas suas mãos." Como o que você deve proteger é diferente, a forma de defendê-lo também é diferente.
Por que a autenticação por chave é mais segura?
Conclusão: A chave privada nunca trafega pela rede (então não pode ser interceptada), o espaço de chaves é efetivamente impossível de forçar bruta, e um comprometimento do servidor não pode revelar a chave privada.
A segurança da autenticação por chave vem principalmente de três propriedades estruturais.
1. O segredo nunca trafega pela rede
Com autenticação por senha, a própria senha chega ao servidor, criptografada mas presente. Com autenticação por chave, a chave privada permanece no cliente; o que é enviado é apenas uma assinatura (uma prova feita com a chave privada). A chave privada em si nunca está na rede.
2. Força bruta é efetivamente impossível
Senhas memoráveis por humanos são limitadas em comprimento e complexidade, tornando-as alvos de ataques de força bruta e dicionário. Uma chave Ed25519, ou RSA de 2048 bits ou mais, tem um espaço de chaves astronomicamente grande, tornando a força bruta impraticável.
3. Resiliente a comprometimento do servidor
O servidor armazena apenas sua chave pública. Você não pode derivar a chave privada a partir da chave pública, então mesmo que authorized_keys vaze, ninguém ganha a capacidade de fazer login. Esta é uma situação diferente de um hash de senha vazado, que é o ponto de partida para cracking offline.
"A autenticação por chave é segura" vale somente enquanto a chave privada estiver protegida. Se o arquivo de chave privada for roubado, a proteção desaparece. O que você protege simplesmente muda de uma senha para um arquivo de chave privada.
Como as chaves pública e privada funcionam?
Conclusão: O cliente assina com a chave privada e o servidor verifica com a chave pública correspondente. Você prova a posse da chave privada sem nunca enviá-la.
A autenticação por chave funciona como um desafio-resposta de chave pública. O fluxo é, resumidamente:
- O cliente informa ao servidor "quero autenticar com esta chave pública."
- O servidor verifica se existe uma chave pública correspondente em
authorized_keys. - O cliente assina dados específicos da sessão com a chave privada e retorna.
- O servidor verifica a assinatura com a chave pública. Uma correspondência significa que você é quem afirma ser.
O ponto-chave: a assinatura é feita sobre dados únicos para cada sessão, então interceptar e reproduzir tráfego passado não ajuda no próximo login. A chave privada em si nunca vai para a rede.
Pense na chave pública como um cadeado que você pode distribuir livremente, e na chave privada como a chave que você mantém escondida. Você pode colocar o cadeado (chave pública) em qualquer número de servidores, mas apenas quem possui a chave correspondente (chave privada) pode abri-lo.
Como criar e instalar um par de chaves?
Conclusão: Crie um par com
ssh-keygen -t ed25519, depois instale a chave pública noauthorized_keysdo servidor comssh-copy-id.
1. Criar um par de chaves
$ ssh-keygen -t ed25519 -C "you@example.com"
-t ed25519: o algoritmo atualmente recomendado (rápido e seguro; para ambientes mais antigos use-t rsa -b 4096)-C: um comentário (um rótulo para identificar a chave depois)- Saída: a chave privada
~/.ssh/id_ed25519e a chave pública~/.ssh/id_ed25519.pub
Você será solicitado a definir uma frase-senha. Esta é uma chave extra que criptografa o próprio arquivo de chave privada, e defini-la é fortemente recomendado (veja abaixo).
2. Instalar a chave pública no servidor
$ ssh-copy-id user@server
ssh-copy-id adiciona com segurança a chave pública ao ~/.ssh/authorized_keys do servidor e define as permissões corretas. Para fazer manualmente, adicione o conteúdo da chave pública (o arquivo .pub) como uma linha em authorized_keys.
Instale apenas a chave pública (.pub). Nunca copie a chave privada (id_ed25519) para o servidor. A regra fundamental é que a chave privada nunca sai do seu cliente.
3. Verificar a conexão
$ ssh user@server
Sucesso significa que você faz login sem um prompt de senha (ou apenas com sua frase-senha).
Deve-se desativar a autenticação por senha?
Conclusão: Após confirmar que a autenticação por chave funciona de forma confiável, desativar a autenticação por senha em servidores de produção é o padrão. Isso fecha fisicamente a porta para ataques de força bruta.
Mesmo com a autenticação por chave habilitada, deixar a autenticação por senha ativa mantém o ponto de entrada de força bruta aberto. Desative-a em /etc/ssh/sshd_config.
# /etc/ssh/sshd_config PubkeyAuthentication yes PasswordAuthentication no
Depois reinicie o serviço SSH.
$ sudo systemctl restart ssh # Família Debian / Ubuntu # Na família RHEL o serviço se chama sshd $ sudo systemctl restart sshd
Cuidado para não se bloquear. Antes de desativar a autenticação por senha, confirme em um terminal separado que o login por chave funciona. Mantenha sua sessão atual aberta e teste com uma nova conexão. Desative enquanto a autenticação por chave está quebrada e você também se bloqueia.
Como manter a chave privada segura?
Conclusão: Defina uma frase-senha, restrinja as permissões de
~/.sshe da chave privada, e usessh-agentpara reduzir a digitação.
A segurança da autenticação por chave depende de proteger a chave privada. No mínimo, faça o seguinte.
Definir uma frase-senha
Uma frase-senha na chave privada significa que um arquivo roubado não é imediatamente utilizável. O momento mais fácil para defini-la é durante o ssh-keygen.
Restringir permissões
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/id_ed25519 $ chmod 600 ~/.ssh/authorized_keys
O OpenSSH recusa autenticação se a chave privada ou ~/.ssh tiver permissões muito permissivas. Este é um lugar clássico para ser rejeitado com um erro de permissões.
Usar ssh-agent para reduzir a digitação
$ eval "$(ssh-agent -s)" $ ssh-add ~/.ssh/id_ed25519
Com a chave desbloqueada mantida pelo ssh-agent, você não precisa redigitar a frase-senha durante a sessão. Você obtém segurança (uma frase-senha está definida) e conveniência.
Não faça:
- Compartilhar uma chave privada por email, chat ou armazenamento em nuvem
- Reutilizar uma chave privada entre múltiplas pessoas (você perde a responsabilidade individual)
- Deixar uma chave privada sem frase-senha em um laptop que você carrega por aí