Como reforçar o SSH de um VPS com chaves e Fail2ban

Por que o SSH é a primeira coisa a proteger

O SSH é o meio de controlar o servidor. Por isso, é a primeira fechadura que os atacantes tentam abrir. Assim que um VPS fica online, os scanners começam a tentar adivinhar nomes de utilizador e palavras-passe na porta 22. Pode monitorizar isso nos logs poucos minutos depois. Proteger o SSH consiste em remover aquilo que pode ser adivinhado: desative completamente o início de sessão com palavra-passe, desative o início de sessão da conta root e permita apenas chaves criptográficas. Depois disso, as tentativas constantes deixam de conseguir entrar, porque não existe nenhuma palavra-passe para descobrir.

Isto pressupõe que o SSH já está a funcionar. Se consegue iniciar sessão, pode protegê-lo. Execute os passos pela ordem indicada e mantenha a sessão atual aberta até uma nova sessão funcionar. Assim, um erro não o impede de entrar no servidor.

Passo 1: confirme primeiro que a autenticação por chave funciona

A autenticação por chave substitui uma palavra-passe por um par de chaves: uma chave privada que permanece no seu computador e uma chave pública que coloca no servidor. O servidor confirma que tem a chave privada sem que ela saia alguma vez da sua máquina. Antes de desativar as palavras-passe, confirme que as chaves funcionam. Caso contrário, pode ficar sem acesso ao servidor.

No seu computador, crie uma chave se ainda não tiver uma:

ssh-keygen -t ed25519

Copie a parte pública para o servidor:

ssh-copy-id user@your-server

Em seguida, abra uma nova sessão SSH. Se conseguir iniciar sessão sem que seja solicitada uma palavra-passe, a sua chave funciona e pode desativar as palavras-passe com segurança. Se aparecer Permission denied (publickey), esse erro esconde cinco falhas diferentes, e o resultado de ssh -v indica qual delas existe antes de alterar qualquer outra coisa. Se as chaves forem uma novidade para si ou se utilizar mais do que um computador, os conceitos básicos da gestão de chaves SSH explicam o modelo completo: uma chave por dispositivo, as permissões exigidas pelo sshd e como revogar uma chave quando um portátil desaparece.

Passo 2: Reforce o sshd com um ficheiro drop-in

Não edite /etc/ssh/sshd_config diretamente. O Ubuntu 24.04 lê ficheiros drop-in de /etc/ssh/sshd_config.d/. Um ficheiro pequeno nesse diretório é mais limpo, sobrevive a atualizações de pacotes e é fácil de remover se algo correr mal. O nome é importante: o sshd mantém o primeiro valor que lê para cada definição, e as imagens cloud do Ubuntu incluem 50-cloud-init.conf com PasswordAuthentication yes nesse diretório. Dê ao ficheiro o nome 00- para que seja ordenado antes desse ficheiro e prevaleça; um ficheiro 99- perde silenciosamente. Crie-o:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Coloque o seguinte conteúdo no ficheiro:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Cada linha fecha uma porta de entrada. PasswordAuthentication no é a principal: com as palavras-passe desativadas, um ataque de força bruta não tem palavras-passe para testar. KbdInteractiveAuthentication no fecha um segundo caminho baseado em palavra-passe. PermitRootLogin no significa que um atacante tem de conhecer o seu nome de utilizador e possuir a sua chave, em vez de apenas visar a única conta, root, que existe em todos os sistemas.

Passo 3: Teste a configuração e depois recarregue-a

Verifique se existem erros na configuração antes de a aplicar. Assim, um erro de digitação não pode interromper o serviço:

sudo sshd -t

Se não apresentar nada, a configuração é válida. Recarregue o SSH:

sudo systemctl reload ssh

Depois, verifique as definições que o sshd utiliza efetivamente. Assim, pode detetar se uma configuração drop-in foi sobreposta por outro ficheiro:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Ambos devem indicar no. Agora, sem fechar a sessão atual, abra uma sessão completamente nova a partir de outro terminal. Se conseguir iniciar sessão com a sua chave, terminou. Se houver algum problema, a primeira sessão continua aberta para o corrigir. Esta sobreposição é a rede de segurança, por isso nunca a ignore.

Passo 4: A porta opcional não padrão

Mover o SSH da porta 22 para uma porta como 2222 não o torna realmente mais seguro, porque um atacante determinado verifica todas as portas. O que isto faz é reduzir o ruído nos logs, já que a maioria dos scanners automatizados tenta apenas a porta 22. Se quiser esta alteração, adicione Port 2222 ao ficheiro drop-in, permita primeiro a nova porta na firewall, execute depois sudo systemctl daemon-reload && sudo systemctl restart ssh.socket e ligue-se com ssh -p 2222. No Ubuntu 24.04, ssh.socket controla a porta de escuta, por isso um reload ssh simples mantém o sshd na porta 22; é necessário reiniciar o socket para aplicar a nova porta. Considere isto uma questão de organização, não de proteção.

Etapa 5: Adicione camadas de defesa

As chaves SSH protegidas são a base. Existem mais duas camadas sobre elas.

O Fail2ban monitoriza os logs e bloqueia endereços que continuam a falhar. Isto reduz o ruído dos scanners e expulsa esses endereços rapidamente. É uma combinação natural com a autenticação apenas por chave: consulte Configurar o Fail2ban no Ubuntu para impedir ataques SSH.

Uma medida ainda mais forte é manter o SSH completamente fora da Internet pública. Se colocar o SSH atrás de uma VPN WireGuard e limitar a porta 22 ao túnel na firewall, ninguém fora da VPN consegue sequer alcançá-lo. Assim, deixa de ser possível tentar palavras-passe por força bruta, em vez de ser apenas mais difícil. Tudo isto pressupõe uma firewall subjacente com política de bloqueio por predefinição, que é configurada com UFW no VPS.

O SSH é apenas uma linha de uma lista de verificação mais ampla: os primeiros 10 minutos num VPS novo apresenta os passos pela ordem correta, e as atualizações automáticas de segurança no Ubuntu mantêm o sistema atualizado depois. Proteger o acesso ao servidor não protege os serviços que estão atrás dele. Por isso, se este mesmo VPS executar um cofre de palavras-passe, uma revisão de proteção do Vaultwarden cobre os dois elementos que a autenticação por chave nunca protege: o token de administrador e o ficheiro de cópia de segurança.

FAQ

Como desativo o início de sessão por palavra-passe no SSH no Ubuntu 24.04?

Crie um ficheiro drop-in em /etc/ssh/sshd_config.d/00-hardening.conf (o prefixo 00 faz com que seja ordenado antes de 50-cloud-init.conf, cujo PasswordAuthentication yes teria precedência, porque o sshd mantém o primeiro valor que lê) com PasswordAuthentication no e KbdInteractiveAuthentication no, execute sudo sshd -t para o validar e, em seguida, execute sudo systemctl reload ssh. Confirme que o início de sessão com chave funciona numa nova sessão antes de depender dele. Editar um drop-in em vez de sshd_config permite sobreviver às atualizações de pacotes e facilita a reversão.

Devo desativar o início de sessão do root através de SSH?

Sim. Defina PermitRootLogin no para impedir o início de sessão direto como root. Inicie sessão com o seu utilizador normal e use sudo para tarefas administrativas. A conta root existe em todos os sistemas Linux, por isso deixá-la acessível fornece a um atacante um nome de utilizador conhecido para tentar. Desativá-la obriga o atacante a conhecer o nome da sua conta e a possuir a sua chave.

Alterar a porta do SSH torna o meu servidor mais seguro?

Não de forma significativa. Mudar da porta 22 faz com que deixe de ser detetado por scanners pouco sofisticados que testam apenas a 22, o que reduz o ruído nos logs, mas um atacante real testa todas as portas e encontra-a na mesma. A autenticação apenas com chaves é o que impede efetivamente as intrusões. Se alterar a porta, abra primeiro a nova porta na firewall e depois execute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; no Ubuntu 24.04, o socket é responsável pelo listener, e um reload simples deixa o sshd na porta 22.

Preciso do Fail2ban se usar chaves SSH?

É opcional, mas continua a ser útil. Com a autenticação apenas com chaves, as tentativas de adivinhar palavras-passe não podem ter sucesso, por isso não é o Fail2ban que mantém os atacantes afastados. Este limita a taxa de falhas repetidas de um endereço, reduzindo o ruído dos scanners nos logs e bloqueando cedo os atacantes reincidentes; um ataque lento e distribuído permanece abaixo do limite de bloqueio. Execute-o juntamente com a autenticação por chave e, idealmente, mantenha o SSH atrás de uma VPN.

Como recupero se perder o acesso ao SSH?

Use a consola web do seu fornecedor, que acede ao servidor através de uma ligação serial ou VNC que não passa pelo SSH. A partir daí, pode iniciar sessão, corrigir o ficheiro drop-in sshd e recarregar o serviço. É precisamente por isso que deve testar uma nova configuração SSH num segundo terminal antes de fechar a primeira sessão e por que a autenticação por chave já deve estar a funcionar antes de desativar as palavras-passe.