Hardening SSH no Ubuntu: Desative Senhas e Use Chaves Ed25519

O hardening SSH é uma das práticas mais críticas para garantir a integridade de um servidor Linux, especialmente em ambientes de VPS expostos à internet. Senhas são vulneráveis a ataques de força bruta e dicionário, que podem comprometer sua infraestrutura em minutos se não houver proteção adequada. A migração para autenticação baseada em chaves, especificamente utilizando o algoritmo Ed25519, oferece um nível de segurança superior, maior velocidade na troca de chaves e resistência a ataques criptográficos modernos.

Neste tutorial técnico, demonstraremos como configurar seu servidor Ubuntu para aceitar apenas autenticação por chaves privadas, desabilitando completamente o acesso via senha. Este processo é essencial para profissionais de TI, sysadmins e desenvolvedores que buscam segurança linux robusta em seus ambientes de produção.

Pré-requisitos e Preparação do Ambiente

Antes de modificar qualquer configuração crítica de segurança, é fundamental garantir que você tenha acesso físico ou alternativo ao servidor. Se você perder a conexão SSH durante o processo de desabilitação de senhas e não tiver outra forma de acesso (como console na nuvem ou IPMI/iLO), ficará bloqueado.

Aviso Importante: Nunca execute este tutorial em um servidor principal sem antes testar em um ambiente de staging ou garantir que você possui uma sessão SSH ativa paralela para recuperação, caso algo falhe. Além disso, certifique-se de ter privilégios de root ou de um usuário com permissões sudo.

O primeiro passo é atualizar o sistema operacional para garantir que todos os pacotes estejam na versão mais recente e corrigidos contra vulnerabilidades conhecidas. Em uma VPS Ubuntu, execute:

sudo apt update && sudo apt upgrade -y

Em seguida, verifique se o serviço SSH (sshd) está instalado e em execução. A maioria das distribuições Linux modernas já inclui o OpenSSH Server por padrão.

systemctl status sshd

Se o serviço não estiver ativo, inicie-o:

sudo systemctl start ssh
sudo systemctl enable ssh

Geração de Chaves Ed25519 no Cliente

O algoritmo Ed25519 é recomendado pela comunidade de segurança porque utiliza curvas elípticas que são mais rápidas e seguras que RSA para o mesmo tamanho de chave, além de gerar chaves de tamanho fixo. Ele também é resistente a falhas na geração de números aleatórios.

Execute este comando no seu computador local (cliente), não no servidor. Substitua seu_email@exemplo.com por um identificador útil:

ssh-keygen -t ed25519 -C "seu_email@exemplo.com"

O comando solicitará o local para salvar a chave. Pressione Enter para aceitar o padrão (~/.ssh/id_ed25519). Em seguida, ele pedirá uma frase secreta (passphrase). É altamente recomendável definir uma passphrase forte. Isso adiciona uma camada extra de segurança: mesmo que seu arquivo de chave privada seja roubado, o atacante não poderá usá-lo sem a senha.

A saída do comando será semelhante a esta:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase): [digite uma senha forte]
Enter same passphrase again: [confirme a senha]
Your identification has been saved in /home/user/.ssh/id_ed25519.
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.

Cópia da Chave Pública para o Servidor

Agora que a chave foi gerada, precisamos copiar a parte pública dela para o servidor alvo. O utilitário ssh-copy-id automatiza esse processo, adicionando a chave ao arquivo ~/.ssh/authorized_keys do usuário remoto.

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@seu_servidor_ubuntu_vps

O sistema pedirá a senha do usuário remoto para autenticação inicial. Após a conexão bem-sucedida, verifique se a chave foi adicionada corretamente:

ssh usuario@seu_servidor_ubuntu_vps

Se você configurou uma passphrase, o cliente local pedirá essa senha. Se o login ocorrer sem solicitar a senha do usuário remoto (apenas a sua passphrase local ou nada, se não tiver definido), a chave foi instalada com sucesso.

Configuração do Arquivo sshd_config

Agora vamos alterar as configurações do daemon SSH no servidor para impor o uso exclusivo de chaves. O arquivo principal de configuração do OpenSSH em sistemas Debian/Ubuntu é /etc/ssh/sshd_config.

Faça um backup da configuração atual antes de editá-la:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Abra o arquivo de configuração usando seu editor de texto preferido, como o nano ou vim:

sudo nano /etc/ssh/sshd_config

Dentro do arquivo, procure pelas seguintes diretrizes e altere seus valores conforme indicado abaixo. Se a linha estiver comentada (iniciando com #), descomente-a removendo o hashtag.

1. Desabilitar Autenticação por Senha

Para garantir que ninguém possa fazer login usando senhas, altere a opção PasswordAuthentication para no:

PasswordAuthentication no

Esta é a configuração central do nosso objetivo de desabilitar senha ssh. Sem essa linha definida explicitamente como "no", algumas versões ou configurações padrão podem ainda permitir senhas, dependendo de outras diretivas.

2. Garantir o Uso de Chaves Públicas

Verifique se a opção PubkeyAuthentication está habilitada:

PubkeyAuthentication yes

Isso garante que o servidor esteja pronto para aceitar chaves públicas. Em versões modernas do OpenSSH, isso é padrão, mas explicitar evita ambiguidades.

3. Restringir Acesso ao Arquivo Authorized Keys

Para maior segurança, adicione ou verifique as seguintes linhas para garantir que o SSH ignore arquivos de chaves se as permissões do diretório home ou do arquivo .ssh estiverem incorretas:

StrictModes yes

O StrictModes faz com que o sshd verifique as permissões e propriedade dos arquivos de login antes de aceitar a autenticação. Isso impede que usuários maliciosos modifiquem arquivos de chave se tiverem acesso ao diretório home.

4. Otimizações Adicionais de Segurança

Além da troca de chaves, recomendamos ajustar outras configurações para server hardening:

• PermitRootLogin no: Desabilita o login direto como root. Use um usuário sudo e eleve os privilégios quando necessário.
• X11Forwarding no: Desativa o encaminhamento X11, reduzindo a superfície de ataque.
• MaxAuthTries 3: Limita o número de tentativas de autenticação falhas antes de fechar a conexão.

Exemplo de configuração consolidada:

# Segurança Básica
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
StrictModes yes
MaxAuthTries 3

# Desativa funcionalidades desnecessárias
X11Forwarding no
UsePAM yes

Após realizar as alterações, salve o arquivo e saia do editor. No Nano, isso é feito com Ctrl+O, Enter, e depois Ctrl+X.

Reiniciar o Serviço SSH

Para aplicar as mudanças, reinicie o serviço sshd:

sudo systemctl restart ssh

Verifique se não houve erros de sintaxe na configuração antes de fechar sua sessão atual:

sudo sshd -t

Se o comando retornar silêncio, a configuração está válida. Se houver erros, ele exibirá a linha problemática. Corrija quaisquer erros antes de prosseguir.

Teste de Conexão e Validação

Não feche sua sessão SSH atual! Abra um novo terminal em seu computador local e tente conectar ao servidor usando a nova chave:

ssh -i ~/.ssh/id_ed25519 usuario@seu_servidor_ubuntu_vps

Se você configurou uma passphrase, ela será solicitada. Se o login for bem-sucedido, tente conectar novamente usando a opção -o PasswordAuthentication=yes para simular um ataque de senha:

ssh -o PasswordAuthentication=yes usuario@seu_servidor_ubuntu_vps

O servidor deve rejeitar imediatamente a tentativa ou solicitar apenas a chave, ignorando qualquer senha digitada. Se você tentar login como root e tiver desabilitado PermitRootLogin, receberá uma mensagem de "Permission denied".

Solução de Problemas Comuns

Se você perder o acesso após a configuração, aqui estão os passos para recuperação:

1. Acesso via Console da Nuvem: A maioria dos provedores de VPS oferece um console web no painel de controle. Use-o para acessar o servidor e reverter as alterações no /etc/ssh/sshd_config.
2. Verificar Permissões: Problemas frequentes envolvem permissões incorretas nas chaves do cliente ou do servidor. No servidor, execute:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys

   No cliente local:

   chmod 600 ~/.ssh/id_ed25519

3. Logs do Sistema: Se a conexão falhar silenciosamente, verifique os logs no servidor para entender o motivo da rejeição:

   sudo tail -f /var/log/auth.log

   Procure por mensagens como "Authentication refused" ou "Bad ownership or modes".

Mantendo a Segurança em Dia

O hardening SSH não é um evento único, mas um processo contínuo. Considere implementar as seguintes práticas complementares:

• Fail2Ban: Instale e configure o Fail2Ban para bloquear IPs que realizarem muitas tentativas de login falhas. Mesmo com senhas desabilitadas, scanners automatizados ainda tentarão acessar portas abertas.
• Atualizações Regulares: Mantenha o OpenSSH atualizado via apt upgrade para proteger contra vulnerabilidades zero-day.
• Gestão de Chaves: Revogue chaves antigas ou comprometidas removendo-as do arquivo ~/.ssh/authorized_keys.
• Porta Padrão: Embora não seja uma medida de segurança absoluta (security through obscurity), mudar a porta padrão do SSH para uma número alto pode reduzir o ruído de scans automatizados.

Conclusão

Ao desabilitar senhas e adotar chaves Ed25519, você elevou significativamente a barreira de entrada para atacantes em seu servidor Ubuntu. Esta configuração é o padrão da indústria para ambientes profissionais e garante que apenas usuários com acesso físico ou lógico à chave privada possam autenticar.

Lembre-se: a segurança depende tanto da configuração técnica quanto da disciplina operacional. Nunca compartilhe suas chaves privadas, mantenha suas passphrases seguras e monitore os logs de autenticação regularmente. Com essa base sólida, sua infraestrutura está preparada para enfrentar ameaças modernas com resiliência.

Para dúvidas ou otimizações específicas de segurança linux em ambientes cloud, consulte a documentação oficial do OpenSSH e mantenha-se atualizado sobre as melhores práticas de configuração sshd.