Chave SSH vs Autenticação por Senha - Por Que as Chaves Vencem

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:

  1. O cliente informa ao servidor "quero autenticar com esta chave pública."
  2. O servidor verifica se existe uma chave pública correspondente em authorized_keys.
  3. O cliente assina dados específicos da sessão com a chave privada e retorna.
  4. 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 no authorized_keys do servidor com ssh-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_ed25519 e 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

Como manter a chave privada segura?

Conclusão: Defina uma frase-senha, restrinja as permissões de ~/.ssh e da chave privada, e use ssh-agent para 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í

Resumo: checklist para migrar para autenticação por chave

A autenticação por chave é segura por sua própria estrutura: o segredo nunca vai para a rede. Migre nesta ordem para evitar acidentes.

  • Crie uma chave protegida por frase-senha com ssh-keygen -t ed25519
  • Instale a chave pública com ssh-copy-id e confirme o login por chave em uma sessão separada
  • Restrinja ~/.ssh e a chave privada para permissões 700 / 600
  • Somente após o login por chave funcionar de forma confiável, defina PasswordAuthentication no

Leia a seguir para aprofundar seu entendimento: