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.

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.

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
- NIST Guidance - https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQE1rgy-YvTfz8ElOMMJpSdOXOB9wjuIQaL00FcywtkL8VrXr4Ds3iRvQR1igoplv3GbW9CtqS9A8p-oQVtF5lLFBQ1be6lCH1ZV_iHO5HmF9mcrr-xmppc7NpyKl4AG
- OpenSSH.org Release Notes - https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQElSpSZ32Te-OHrOFdZketQSutA0eaaKeMRP9wX7bVAJy0tCp5fv5nCdadEpJlvx9KEpSFqLSdfrptse5481NH0oSTeFWGUdKNtcgcU4w7FasKqqfZAAfiGiH_OAB4NmcbzghQn
- SANS Institute - https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFRnkWUmN37AJHYEAQWvgOFrwfPqdV6aT2ItBj9szz0emnYuTsBIawM_zQ8LNtEMwgb5UFFzS4-slW7zuQey0P7i6uVtq7tXIsUaKn3xBkdU2mfGwkoC1NPua4pg3jt6XdyaLeq4Nedi9Qtr2l7SvsfT4RFql-_RReO1AZ2gYxW14A8phe_05881kOGpRtD9gXXNIYIUwBcuzzfiKp7X1TALFUG9Iaov5xn9Ho5kvruCzOpzUI=
- Ikarus.sg - https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQFOyvLk7pUciX9D1Z3pCEnpF5Porx2CKRi5l0aVdan4mR8iZ5RjThwPDIGBImtKy6a2FfUU89jhFrNWu8zMMEJaIiL3vx_U7awd4p_lLIGEvIGUu4Mc5o9Zj5iqIJ8=
- Cloud Fellows - https://vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQEdbLSBjVFA8qkmTeWCGDAblMcqOyn1YZa6r9cQRF-0PwdlNlo37Nv8C_uYhAlmuuaZKJuGmKd_PkMnmoVjNAmOO0QfyuKh18kxRzY-B4h2FGTFaW6dMu1xi_diETajfaSaXl67RP3GuXvyC8SdCWQ6YunTFCoCU56_
0 Comentários