Hardening SSH: Por que usar Chaves em vez de Senhas?

A segurança de um servidor Linux é a linha de defesa primordial contra ataques automatizados, bots e intrusões mal-intencionadas. Um dos erros mais comuns cometidos por administradores iniciantes e até profissionais experientes é a dependência excessiva de senhas para autenticação SSH (Secure Shell). Embora as senhas sejam convenientes, elas são vulneráveis a ataques de força bruta, dicionário e phishing. A migração para SSH keys não é apenas uma boa prática; é um requisito fundamental para qualquer ambiente de produção sério.

Neste tutorial completo, vamos abordar por que você deve migrar imediatamente, como gerar e configurar chaves SSH seguras, como desabilitar o acesso por senha e, finalmente, como implementar camadas extras de segurança com UFW, Fail2ban e CrowdSec. Este guia é essencial para quem busca um verdadeiro hardening Linux em sua VPS ou servidor dedicado.

A Falácia da Segurança Baseada em Senhas

Muitos usuários acreditam que uma senha complexa, como P@ssw0rd!2024#Secure, é suficiente para proteger o acesso remoto. A realidade técnica é diferente. Scripts de ataque automatizados varrem a internet 24 horas por dia, testando milhões de combinações contra a porta 22 (ou outra definida pelo administrador). Mesmo que sua senha seja forte, ela pode ser quebrada se for baseada em palavras do dicionário ou padrões comuns.

As SSH keys, por outro lado, utilizam criptografia de chave pública. Isso funciona como um par de cadeado e chave: você tem uma chave privada (que fica apenas no seu computador) e uma chave pública (que fica no servidor). Para acessar o servidor, o cliente precisa provar que possui a chave privada correspondente à chave pública armazenada. A probabilidade de alguém "adivinhar" sua chave privada é estatisticamente insignificante comparada ao risco de uma senha ser comprometida.

Além da segurança superior, as chaves SSH oferecem praticidade. Após configuradas corretamente, você não precisa digitar senhas longas e complexas a cada conexão, agilizando o fluxo de trabalho do desenvolvedor e do sysadmin.

Passo 1: Gerando o Par de Chaves SSH

O primeiro passo é gerar as chaves na sua máquina local (cliente). Recomendamos o uso do algoritmo Ed25519, que é mais rápido e seguro que os antigos RSA ou DSA, utilizando menos recursos computacionais.

Abra seu terminal (Linux, macOS ou Git Bash no Windows) e execute o seguinte comando:

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

O parâmetro -C adiciona um comentário à chave, geralmente seu e-mail, para facilitar a identificação. O sistema solicitará o local para salvar a chave. Pressione Enter para aceitar o padrão (~/.ssh/id_ed25519). Em seguida, você será solicitado a definir uma passphrase (senha da chave).

Atenção: Não pule a passphrase. Uma chave privada sem proteção é como deixar o carro com a chave no contato na rua. A passphrase criptografa sua chave privada em disco, garantindo que, se seu computador for roubado ou invadido, o atacante não conseguirá usar sua chave SSH imediatamente sem saber essa senha.

Passo 2: Copiando a Chave Pública para o Servidor

Agora precisamos colocar a chave pública gerada no servidor Linux que queremos proteger. A maneira mais fácil é usar o comando ssh-copy-id.

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

Se você estiver usando uma porta SSH personalizada (diferente da 22), use a flag -p:

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 usuario@seu_servidor_ip

O comando solicitará a senha atual do usuário no servidor. Após a autenticação, ele copiará o conteúdo de id_ed25519.pub para o arquivo ~/.ssh/authorized_keys do usuário remoto.

Dica Pro: Se você não tiver acesso ao ssh-copy-id (comum em alguns ambientes Windows ou BSD), pode copiar manualmente o conteúdo da chave pública e colá-lo no arquivo ~/.ssh/authorized_keys do servidor, garantindo que cada linha da chave fique em uma linha separada.

Passo 3: Testando a Conexão

Antes de desabilitar o acesso por senha, é crucial testar se a nova configuração funciona. Tente conectar novamente:

ssh usuario@seu_servidor_ip

Se você definiu uma passphrase no Passo 1, o terminal solicitará essa senha. Se tudo estiver correto, você entrará no servidor sem precisar digitar a senha de login do usuário.

Passo 4: Desabilitando a Autenticação por Senha

Agora que a chave está funcionando, vamos aumentar o nível de segurança VPS bloqueando o acesso via senha. Isso impede ataques de força bruta direcionados ao seu usuário.

Edite o arquivo de configuração do SSH no servidor:

sudo nano /etc/ssh/sshd_config

Localize as seguintes diretivas e altere seus valores. Se estiverem comentadas (iniciadas com #), remova o símbolo:

• PermitRootLogin no: Desabilita o login direto do root. Isso é vital para desabilitar root como entrada direta, forçando o uso de sudo.
• PasswordAuthentication no: Desabilita a autenticação por senha.
• ChallengeResponseAuthentication no: Garante que nenhum outro método baseado em senha esteja ativo.
• UsePAM no: Em algumas distribuições, isso pode interferir com o PasswordAuthentication; deixe como estava se não tiver certeza, mas geralmente "no" é mais seguro para evitar bypass.

O arquivo deve ficar semelhante a isto:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no

Salve o arquivo (Ctrl+O, Enter, Ctrl+X no nano) e reinicie o serviço SSH para aplicar as mudanças:

sudo systemctl restart sshd

Aviso Crítico: Não feche sua sessão atual! Abra um novo terminal e teste a conexão novamente. Se falhar, você ainda estará na sessão original e poderá corrigir o erro. Se fechar a janela e não conseguir reconectar, terá que usar o console web (VNC/Serial Console) do seu provedor de hospedagem para recuperar o acesso.

Passo 5: Hardening Adicional com UFW

A firewall é a primeira linha de defesa visível. O UFW (Uncomplicated Firewall) no Ubuntu/Debian ou o firewalld no CentOS/RHEL devem ser configurados para permitir apenas o tráfego necessário.

Instale e ative o UFW se ainda não estiver feito:

sudo apt install ufw
sudo ufw enable

Permita apenas SSH, HTTP e HTTPS. Se você mudou a porta SSH no Passo 4 (recomendado), ajuste o comando:

# Porta padrão 22
sudo ufw allow ssh

# Ou porta personalizada, ex: 2222
sudo ufw allow 2222/tcp

# Web
sudo ufw allow http
sudo ufw allow https

Verifique o status:

sudo ufw status

Passo 6: Implementando Fail2ban

Embora tenhamos desabilitado senhas, bots ainda tentarão acessar sua porta SSH. O Fail2ban monitora os logs e bloqueia IPs que realizam muitas tentativas falhas.

Instale o serviço:

sudo apt install fail2ban

Copie a configuração padrão para não perder atualizações:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edite o arquivo jail.local:

sudo nano /etc/fail2ban/jail.local

Configure os parâmetros de banimento. Um exemplo robusto:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Isso significa: se houver 3 tentativas falhas em 10 minutos (findtime), o IP será banido por 1 hora (bantime). Reinicie o serviço:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Passo 7: CrowdSec como Camada Extra de Inteligência

O CrowdSec é uma solução moderna de segurança colaborativa. Diferente do Fail2ban, que opera localmente, o CrowdSec compartilha indicadores de comprometimento com a comunidade global. Se um IP atacar outro servidor na rede CrowdSec, ele será banido automaticamente no seu também.

Instale o agente:

wget -qO- https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec

Inicie a instalação e configure o perfil de segurança:

sudo cscli bootstrapping
sudo systemctl enable --now crowdsec

Instale o bouncer do Fail2ban para integrar os dois sistemas:

sudo apt install fail2ban-bouncer-crowdsec

O CrowdSec fornecerá logs mais detalhados e uma visão centralizada de ameaças, complementando o hardening Linux já realizado.

Passo 8: Boas Práticas Finais

Além das configurações técnicas, adote estes hábitos:

• Não compartilhe chaves privadas: Mantenha sua chave privada segura e nunca a envie por e-mail ou mensageiros não criptografados.
• Rotação de Chaves: Se um colaborador sair da equipe, remova imediatamente sua chave pública do arquivo authorized_keys.
• Backup dos Backups: Guarde uma cópia de segurança das suas chaves privadas em um local físico seguro (como um pen drive criptografado). Se você perder a chave e não tiver backup, perderá o acesso ao servidor.
• Mude a Porta SSH: Embora não seja uma medida de segurança absoluta (security through obscurity), mudar a porta padrão reduz drasticamente o ruído dos logs causados por bots genéricos.

Conclusão

A migração para SSH keys e a configuração adequada de firewalls e sistemas de detecção de intrusão como Fail2ban e CrowdSec transformam uma VPS vulnerável em um servidor resiliente. Essas medidas não apenas protegem seus dados, mas também garantem a disponibilidade do seu serviço contra ataques de negação de serviço (DoS) e intrusões.

Não espere ser a próxima vítima de um ataque de força bruta. Implemente essas etapas hoje mesmo e durma tranquilo sabendo que sua infraestrutura está blindada.