Como mudar a porta padrão SSH (22) e reduzir scanners automatizados

A porta 22 é o alvo padrão de praticamente todo scanner automatizado de SSH na internet. Botnets como Mirai e suas variantes varrem a faixa IPv4 inteira procurando especificamente serviços expostos na 22 — não porque seja a única porta possível, mas porque é a aposta com maior retorno. Resultado: mesmo uma VPS recém-provisionada acumula centenas de tentativas de login falhadas por hora nos logs antes do primeiro deploy.

Trocar a porta padrão não é segurança real contra um atacante direcionado. Um nmap -p- completo acha qualquer porta SSH em segundos. Mas o objetivo aqui é outro: reduzir o ruído operacional. Menos linhas em /var/log/auth.log, menos disparos do fail2ban, menos CPU gasta rejeitando conexões obviamente maliciosas. Em tutoriais que recomendam isso há uma armadilha frequente: a mudança no sshd_config sozinha não funciona em distros modernas porque o systemd intercepta a porta via socket activation.

Este guia leva cerca de 15 minutos e cobre o procedimento completo em Ubuntu 22.04/24.04, Debian 12 e variantes RHEL — incluindo o ajuste no systemd socket, regras de firewall com UFW e firewalld, configuração de SELinux quando aplicável, e o teste obrigatório antes de fechar a sessão atual.

Pré-requisitos

Escolher a nova porta

A nova porta deve ser não-privilegiada (acima de 1024) pra evitar exigência de root em rebinds, e fora da faixa de serviços conhecidos. Faixa recomendada: 1024–49151. Acima de 49152 é a faixa de portas efêmeras, que o kernel usa pra conexões de saída — funciona, mas tecnicamente compete com sockets dinâmicos.

Opções comuns: 2200, 2222, 22022, 4422. Evite portas associadas a outros serviços (3306 MySQL, 5432 PostgreSQL, 6379 Redis, 8080 HTTP alternativo). Pra este tutorial vamos usar 2222 como exemplo — substitua pelo valor que você escolher.

Antes de continuar, confirme que a porta está livre no servidor:

sudo ss -tlnp | grep :2222

Output esperado: vazio. Se aparecer algum processo, escolha outra porta.

Configurar o sshd

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo nano /etc/ssh/sshd_config

Port 2222

sudo sshd -t

Ajustar o systemd socket (passo crítico)

Em Ubuntu 22.04+, Debian 12+ e algumas versões do Fedora, o SSH é ativado via socket do systemd. Isso significa que o systemd escuta na porta 22 e só passa a conexão pro daemon quando recebe um pedido. Mudar só o sshd_config não tem efeito nesse caso — o socket continua na 22.

sudo systemctl status ssh.socket

sudo systemctl stop ssh.socket
sudo systemctl disable ssh.socket
sudo systemctl mask ssh.socket

sudo systemctl enable ssh

Liberar a nova porta no firewall

Esse passo precisa acontecer ANTES de reiniciar o SSH. Se você reiniciar primeiro, o sshd vai começar a escutar na 2222 mas o firewall vai bloquear conexões — e sua sessão atual pode ficar instável durante o restart.

sudo ufw allow 2222/tcp comment 'SSH custom port'

sudo ufw status numbered

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

SELinux (apenas RHEL/CentOS/Rocky/AlmaLinux)

Em distros com SELinux em modo enforcing, o policy bloqueia o sshd de fazer bind em portas não-marcadas como ssh_port_t. Sem esse ajuste, o serviço falha ao reiniciar e o erro aparece em /var/log/audit/audit.log.

sudo dnf install -y policycoreutils-python-utils

sudo semanage port -a -t ssh_port_t -p tcp 2222

sudo semanage port -l | grep ssh

Reiniciar e testar

sudo systemctl restart ssh

sudo ss -tlnp | grep ssh

ssh -p 2222 usuario@seu_ip_da_vps

Fechar a porta 22 antiga

Só faça este passo depois de confirmar que SSH funciona estável na 2222 por pelo menos 10 minutos em uma sessão de teste independente.

sudo ufw delete allow 22/tcp

Ou em firewalld:

sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload

Confirme que a 22 não responde mais:

ss -tlnp | grep :22

Output esperado: vazio. A partir daqui, qualquer conexão na 22 cai imediatamente no firewall — exatamente o comportamento que reduz o ruído nos logs.

Verificação final

Confirme tudo de uma vez com um snapshot do estado:

sudo ss -tlnp | grep ssh
sudo systemctl status ssh
sudo ufw status

Você deve ver: SSH escutando só na 2222, serviço active (running), firewall com 2222/tcp permitida e 22/tcp ausente. Em 24 horas, compare o volume de tentativas falhadas:

sudo journalctl -u ssh --since '24 hours ago' | grep -c 'Failed password'

A queda esperada é de 90%+ em comparação com a 22 exposta — o restante são scanners que fazem range scan ou já mapearam seu IP.

Próximos passos

Mudar a porta é só o primeiro nível de hardening. Próximos passos recomendados:

• Desabilitar autenticação por senha (PasswordAuthentication no no sshd_config) e usar apenas chaves SSH com ed25519.
• Configurar fail2ban com jail customizado pra nova porta — o filtro default do pacote assume 22 e precisa de override.
• Restringir login root: PermitRootLogin prohibit-password (ou no se você tem usuário sudo configurado).
• Habilitar autenticação de dois fatores via Google Authenticator (libpam-google-authenticator).
• Configurar logging centralizado pra correlacionar tentativas entre múltiplas VPS.

Se você está rodando isso em produção, uma VPS Hostini já vem com console serial nativo no painel — então mesmo se você se trancar fora por engano de firewall, é possível recuperar o acesso sem suporte. Conheça as opções em /vps.