como fazer hardening de SSH no VPS

Por que o SSH é a primeira prioridade de hardening

O SSH é a ferramenta de controle do seu servidor, o que o torna o alvo principal de qualquer atacante. Assim que um VPS fica online, scanners começam a testar usuários e senhas na porta 22. Você pode observar isso nos logs em poucos minutos. O hardening do SSH consiste em remover o que pode ser adivinhado: desative o login por senha completamente, desative o login como root e permita apenas chaves criptográficas. Uma vez feito isso, as tentativas de força bruta falham, pois não há senha para ser descoberta.

Isso pressupõe que o SSH já esteja funcionando. Se você consegue logar, você consegue aplicar o hardening. Siga os passos na ordem correta e mantenha sua sessão atual aberta até que uma nova sessão funcione, para evitar que um erro cause o lockout do sistema.

Passo 1: Certifique-se de que a autenticação por chave funciona primeiro

A autenticação por chave substitui a senha por um par de chaves: uma chave privada que permanece no seu computador e uma chave pública que você instala no servidor. O servidor comprova que você possui a chave privada sem que ela saia da sua máquina. Antes de desativar as senhas, confirme se as chaves funcionam para evitar perder o acesso ao sistema.

No seu computador, crie uma chave caso ainda não possua uma:

ssh-keygen -t ed25519

Copie a chave pública para o servidor:

ssh-copy-id user@your-server

Em seguida, abra uma nova sessão SSH. Se o acesso for permitido sem solicitar senha, sua chave funciona e você pode desativar as senhas com segurança. Se você é novo no uso de chaves ou utiliza mais de um computador, conceitos básicos de gerenciamento de chaves SSH explica o modelo completo: uma chave por dispositivo, as permissões exigidas pelo sshd e como revogar uma chave em caso de perda do notebook.

Passo 2: Reforce o sshd usando um arquivo drop-in

Não edite o /etc/ssh/sshd_config diretamente. O Ubuntu 24.04 lê arquivos drop-in do /etc/ssh/sshd_config.d/. Um arquivo pequeno nesse diretório é mais limpo, sobrevive a atualizações de pacotes e é fácil de remover se ocorrer algum erro. O nome é importante: o sshd mantém o primeiro valor lido para cada configuração, e as imagens cloud do Ubuntu trazem o 50-cloud-init.conf com o PasswordAuthentication yes neste diretório. Nomeie seu arquivo como 00- para que ele seja processado antes do original; um arquivo 99- será ignorado silenciosamente. Crie um:

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

Coloque isto em:

# 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. O PasswordAuthentication no é a principal: com senhas desativadas, um ataque de brute-force não tem o que tentar. O KbdInteractiveAuthentication no fecha um segundo caminho baseado em senha. O PermitRootLogin no significa que um atacante deve conhecer seu username e possuir sua chave, em vez de apenas focar na única conta que existe em todas as máquinas, o root.

Passo 3: Teste a configuração e recarregue

Verifique a configuração em busca de erros antes de aplicá-la, para evitar que um erro de digitação interrompa o serviço:

sudo sshd -t

Se não houver saída, a configuração é válida. Recarregue o SSH:

sudo systemctl reload ssh

Em seguida, verifique as configurações que o sshd está utilizando de fato, para identificar se algum parâmetro foi sobrescrito por outro arquivo:

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

Ambos devem exibir no. Agora, sem fechar sua sessão atual, abra uma nova sessão a partir de outro terminal. Se o login for realizado com sua chave, o processo foi concluído. Se algo estiver errado, sua primeira sessão ainda estará aberta para correção. Essa sobreposição é sua rede de segurança; nunca a ignore.

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

Mover o SSH da porta 22 para algo como 2222 não aumenta a segurança real, pois um atacante determinado fará scan em todas as portas. Isso apenas reduz o ruído nos logs, já que a maioria dos scanners automatizados tenta apenas a porta 22. Se desejar, adicione Port 2222 ao seu arquivo de configuração, libere a nova porta no firewall, execute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket e conecte-se via ssh -p 2222. No Ubuntu 24.04, o ssh.socket gerencia a porta de escuta, portanto, um simples reload ssh mantém o sshd na porta 22; reiniciar o socket é necessário para aplicar a nova porta. Considere isso uma organização, não uma proteção.

Passo 5: Adicione camadas de defesa adicionais

Chaves SSH protegidas são a base, e duas camadas extras funcionam sobre elas.

O Fail2ban monitora seus logs e bane endereços com falhas repetitivas, o que reduz o ruído de scanners e os remove cedo. Ele combina perfeitamente com autenticação apenas por chave: veja Fail2ban no Ubuntu para interromper ataques SSH.

Ainda mais seguro é manter o SSH totalmente fora da internet pública. Se você colocar o SSH atrás de uma VPN WireGuard e restringir a porta 22 ao túnel, ninguém fora da VPN conseguirá acessá-lo; assim, ataques de brute-force deixam de ser apenas difíceis e tornam-se impossíveis. Tudo isso assume um firewall com política de negação padrão, como o UFW configurado no VPS.

O SSH é apenas um item de um checklist maior: os primeiros 10 minutos em um novo VPS organiza os passos por ordem de execução, e atualizações de segurança automáticas no Ubuntu mantém o servidor corrigido posteriormente.

FAQ

Como desabilito o login por senha no SSH no Ubuntu 24.04?

Crie um arquivo drop-in em /etc/ssh/sshd_config.d/00-hardening.conf (o prefixo 00 faz com que ele seja ordenado antes de 50-cloud-init.conf, cujo PasswordAuthentication yes venceria caso contrário, pois o sshd mantém o primeiro valor lido) contendo PasswordAuthentication no e KbdInteractiveAuthentication no, execute sudo sshd -t para validar e depois sudo systemctl reload ssh. Confirme se o login por chave funciona em uma nova sessão antes de confiar na alteração. Editar um drop-in em vez do sshd_config sobrevive a atualizações de pacotes e é fácil de reverter.

Devo desabilitar o login como root via SSH?

Sim. Configure PermitRootLogin no para que ninguém consiga logar diretamente como root. Logue com seu usuário comum e use sudo para tarefas administrativas. O usuário root existe em todo sistema Linux, então deixá-lo acessível fornece um nome de usuário conhecido para o atacante. Desabilitá-lo exige que o atacante conheça seu nome de usuário e possua sua chave.

Mudar a porta do SSH torna meu servidor mais seguro?

Não significativamente. Mudar da porta 22 esconde você de scanners preguiçosos que apenas testam a porta 22, o que reduz o ruído nos logs, mas um atacante real escaneia todas as portas e a encontrará de qualquer forma. A autenticação apenas por chave é o que realmente impede invasões. Se você alterar a porta, abra a nova porta no firewall primeiro e depois execute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; no Ubuntu 24.04, o socket gerencia o listener, e um reload simples mantém o sshd na porta 22.

Preciso do Fail2ban se eu usar chaves SSH?

É opcional, mas ainda é útil. Com autenticação apenas por chave, tentativas de adivinhação de senha não funcionam, portanto o Fail2ban não é o que impede atacantes. Ele limita a taxa de falhas repetidas de um único endereço, o que reduz o ruído de scanners nos logs e bane infratores recorrentes rapidamente; um ataque lento e distribuído permanece abaixo do limite de banimento de qualquer maneira. Use-o junto com a autenticação por chave e, idealmente, mantenha o SSH atrás de uma VPN.

Como faço a recuperação se eu perder o acesso ao SSH?

Use o console web do seu provedor, que acessa o servidor via conexão serial ou VNC que não depende do SSH. Por lá, você pode logar, corrigir o arquivo drop-in sshd e recarregar o serviço. É exatamente por isso que você deve testar uma nova configuração de SSH em um segundo terminal antes de fechar sua primeira sessão, e por isso a autenticação por chave deve estar funcionando antes de desativar as senhas.