1

Uso configurações similares + fail2ban a pelo menos 12 anos, servidores sempre públicos e nunca tive problemas.

Além disso para quem tem IP fixo e usa em cloud que oferece firewall na rede, sugiro liberar o acesso a porta do SSH apenas para seu IP.

Para quem não tem IP fixo, você pode fazer o mesmo, já que muitos provedores de internet demoram a forçar o rotacionamento do IP, então as vezes você precisará acessar o painel e atualizar o IP.

Você também pode fazer de forma automática a atualização, maioria das clouds tem API, então basta um script com duas requisições, uma para pegar seu IP público e outra para atualizar a regra do firewall da cloud.

Carregando publicação patrocinada...
1

Boa! Concordo.

Se houver IP fixo, liberar a porta 22 somente para o IP administrativo no firewall da própria cloud é ainda melhor, porque o tráfego indesejado nem chega ao servidor.

Para IP dinâmico, essa automação via API também é uma solução interessante. Só acrescentaria o cuidado de usar um token com permissão mínima, restrito apenas à alteração daquela regra de firewall, para não transformar o script em outro ponto de risco.

Nesse cenário, eu vejo as camadas mais ou menos assim:

Firewall da cloud com allowlist de IP → chave SSH Ed25519 → PermitRootLogin no → PasswordAuthentication no → Fail2ban como camada adicional.

E trocar a porta 22 acaba sendo mais redução de ruído de bot do que uma medida real de segurança.