SSH com Chave: Como Configurar e Desativar o Login por Senha

Configurar o acesso SSH por chave e desativar o login por senha exige três etapas fundamentais: gerar um par de chaves modernas utilizando o algoritmo Ed25519 (ssh-keygen -t ed25519), transferir a chave pública para o arquivo authorized_keys do servidor e, por fim, alterar as diretivas PasswordAuthentication no e PermitRootLogin no no arquivo /etc/ssh/sshd_config. Essa abordagem elimina o risco de invasões por ataques de força bruta, tornando a infraestrutura imediatamente compatível com os padrões de segurança atuais.

Principais Aprendizados

  • O algoritmo Ed25519 é o padrão atual recomendado para novas chaves SSH, oferecendo alta performance e segurança superior em um tamanho compacto.
  • Desativar o login por senha exige testes rigorosos em uma segunda janela de terminal antes de reiniciar o serviço, prevenindo o bloqueio acidental (lockout).
  • A fundação OpenSSH já tornou obsoleto o uso de assinaturas SHA-1 e está pavimentando o caminho para a criptografia pós-quântica em suas atualizações mais recentes.

O Fim das Senhas e o Padrão Ed25519

Expor a porta 22 na internet pública com autenticação por senha resulta em ataques de força bruta em questão de minutos. Bots automatizados varrem a rede constantemente em busca de credenciais fracas. Ao expor um servidor na internet, seja para hospedar um site ou configurar um proxy reverso, a transição para chaves criptográficas deixa de ser uma opção e torna-se um requisito básico de conformidade (como SOC 2 e ISO 27001).

O consenso da área aponta que o algoritmo de curva elíptica Ed25519 é o padrão ouro atual. Ele substituiu o uso tradicional do RSA em novas implementações devido à sua velocidade e segurança. Segundo as orientações do NIST, o Ed25519 oferece o mesmo nível de proteção que chaves RSA muito maiores.

Terminal executando a geração de chave SSH Ed25519

Passo a Passo: Configurando o SSH com Chave

1. Gerando a Chave Criptográfica

No computador cliente (sua máquina local), abra o terminal e execute o comando de geração especificando o algoritmo correto:

ssh-keygen -t ed25519 -C "[email protected]"

O sistema solicitará um local para salvar a chave e, em seguida, uma passphrase (senha da chave privada). Um erro comum é gerar chaves sem essa senha por conveniência. A recomendação técnica é sempre utilizar uma passphrase forte; caso seu computador local seja comprometido, a criptografia em repouso impedirá que o invasor utilize a chave para acessar o servidor.

2. Copiando a Chave para o Servidor

Com o par de chaves gerado, é necessário enviar a chave pública para o servidor. Para quem está montando um laboratório, como criar uma VM no Proxmox, o utilitário mais seguro e direto é o ssh-copy-id:

ssh-copy-id usuario@ip_do_servidor

Este comando insere automaticamente o conteúdo da sua chave pública no arquivo ~/.ssh/authorized_keys do servidor com as permissões corretas.

Desativando o Login por Senha com Segurança

O Perigo do "Lockout" (Acesso Bloqueado)

O erro mais crítico durante essa configuração é trancar a si mesmo fora do servidor. Isso ocorre quando o administrador desativa as senhas e reinicia o serviço SSH antes de confirmar se a chave pública está funcionando. Na prática, o mais indicado é manter a sessão atual aberta, abrir uma segunda janela de terminal e tentar fazer o login via chave. Apenas prossiga se o acesso ocorrer sem pedir a senha do usuário do sistema operacional.

Editando o sshd_config

Com o acesso por chave validado, acesse o arquivo principal de configuração do servidor:

sudo nano /etc/ssh/sshd_config

Localize e modifique as seguintes diretivas exatas:

  • PasswordAuthentication no (Desativa o login por senha)
  • PubkeyAuthentication yes (Garante que o login por chave está ativo)
  • PermitRootLogin no (Impede o acesso direto com o usuário root)

Após salvar o arquivo, reinicie o serviço para aplicar as mudanças (sudo systemctl restart ssh ou sshd, dependendo da distribuição). Uma prática emergente de segurança é configurar PasswordAuthentication no também no arquivo de configuração do cliente (~/.ssh/config), prevenindo vazamentos caso o usuário se conecte acidentalmente a um servidor falso.

Criptografia Moderna e o Futuro do OpenSSH

Existe um mito de que o algoritmo RSA foi descontinuado ou está morto. O que ocorreu, de fato, foi que desde a versão 8.8 (lançada no final de 2021), o OpenSSH desativou por padrão o esquema de assinatura ssh-rsa, que utilizava o hash SHA-1, considerado vulnerável. As chaves RSA continuam válidas, desde que utilizem assinaturas SHA-2 (rsa-sha2-256 ou rsa-sha2-512) e possuam no mínimo 3072 bits, sendo 4096 bits o mais comum para sistemas legados.

O ecossistema está em rápida evolução. Conforme as notas de lançamento do OpenSSH, a versão 10.5 (agosto de 2026) tornou obrigatório o suporte a ECC (Criptografia de Curva Elíptica), reforçando a transição definitiva para curvas como o Ed25519. Além disso, a versão 10.4 já introduziu suporte experimental para assinaturas compostas pós-quânticas (ML-DSA-44 + Ed25519), preparando a infraestrutura para ameaças futuras.

Comparação visual entre chaves RSA e Ed25519

Perguntas Frequentes

Mudar a porta padrão do SSH (22) aumenta a segurança?

Há uma controvérsia em aberto sobre essa prática. Uma vertente argumenta que é apenas "segurança por obscuridade", pois um scan de portas simples descobre o serviço facilmente. Por outro lado, defensores da mudança apontam que, embora não impeça ataques direcionados, alterar a porta reduz drasticamente o "ruído" de bots automatizados nos logs do servidor, economizando recursos de processamento.

Posso usar chaves ECDSA no lugar de Ed25519?

Embora o ECDSA seja suportado, o consenso da comunidade de criptografia prefere o Ed25519. O ECDSA depende de curvas matemáticas do NIST que historicamente levantaram suspeitas sobre possíveis backdoors, além de ser mais suscetível a falhas caso o gerador de números aleatórios do sistema apresente problemas.

O que acontece se eu perder minha chave privada?

Se a chave privada for perdida e o login por senha estiver desativado no servidor, você perderá o acesso remoto via SSH. A recuperação só será possível através de acesso físico ao servidor ou utilizando consoles virtuais (VNC/KVM) fornecidos pelo seu provedor de hospedagem em nuvem para reverter a configuração no arquivo sshd_config.

Fontes

Postar um comentário

0 Comentários

Contact form