Como alterar a porta do SSH no Linux de forma segura

O protocolo Secure Shell (SSH) é a principal porta de entrada para a administração remota de servidores Linux. Por padrão, o daemon do SSH (sshd) escuta na porta TCP 22. Essa padronização, embora facilite a conectividade inicial, torna os servidores alvos constantes de escaneamentos automatizados de portas por agentes maliciosos e ataques massivos de força bruta (brute-force).

1. Fundamentos de hardening de rede e SSH#

Alterar a porta do SSH não é uma solução completa de segurança por si só (segurança por obscuridade), mas é um componente central na estratégia de defesa em profundidade (defense in depth):

1. Mitigação de Ataques Automatizados: A grande maioria dos bots de varredura automatizada busca apenas a porta padrão 22. Alterar a porta elimina mais de 99% do ruído nos logs de tentativas de conexões inválidas.
2. Redução de I/O de Disco nos Logs: Reduzir o volume de tentativas de conexões brutas evita o preenchimento excessivo de logs do sistema em auth.log (sistemas baseados em Debian/Ubuntu) ou secure (RHEL/Rocky Linux).
3. Foco na Resposta a Incidentes (IR): Com logs limpos de tentativas automatizadas na porta 22, alertas de falha de autenticação na nova porta customizada passam a ser tratados como incidentes altamente direcionados e de alta prioridade.

2. Passo a passo para alteração de porta SSH com segurança#

Abaixo está o fluxo correto de execução das operações necessárias para realizar a alteração sem correr riscos de indisponibilidade de acesso remoto.

Passo 0: Planejamento e escolha de porta segura#

Ao selecionar a nova porta customizada para o SSH, siga estas diretrizes de segurança e redes:

• Portas Acima de 1024: Utilize portas na faixa não-privilegiada (1024 a 65535).
• Evite Portas Reservadas: Consulte services para garantir que a porta escolhida não está reservada para serviços conhecidos.
• Evite Faixas Extremamente Altas: Não use portas acima de 30000, pois elas podem conflitar com a faixa de portas efêmeras usadas para conexões de saída do sistema. A faixa recomendada é entre 10000 e 20000 (por exemplo, 22022).

Antes de prosseguir, certifique-se de que a porta escolhida não está em uso por nenhuma outra aplicação no servidor:

# Verificar sockets de rede usando o comando ss (moderno e recomendado)
sudo ss -tulpn | grep :22022

Se o comando não retornar nenhuma linha de saída, a porta está livre para uso.

Passo 1: Backup preventivo obrigatório#

Antes de modificar qualquer configuração do sistema, crie cópias de segurança de todos os arquivos e diretórios relevantes:

# Backup do arquivo principal com timestamp
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d-%H%M%S)

# Backup do diretório de includes adicionais (.d)
sudo cp -r /etc/ssh/sshd_config.d/ /etc/ssh/sshd_config.d.backup.$(date +%Y%m%d-%H%M%S) 2>/dev/null || true

Passo 2: Configuração dos sistemas de acesso mandatório (MAC)#

Se o seu sistema operacional utiliza mecanismos de controle de acesso obrigatório (MAC), o daemon do SSH será bloqueado de iniciar em uma porta não padronizada a menos que você atualize as regras de segurança do kernel.

SELinux (RHEL, CentOS, Rocky Linux, AlmaLinux)#

1. Verifique o status atual do SELinux:

   getenforce

Se o retorno for Enforcing, você deve adicionar a nova porta de forma explícita nas regras do SELinux.

1. Registre a nova porta TCP no tipo de porta SSH (ssh_port_t):

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

Caso precise testar de forma temporária, você pode alternar o SELinux para o modo permissivo (sudo setenforce 0) e, após validar que o SSH iniciou com sucesso, retornar ao modo de proteção padrão aplicando a regra e reativando (sudo setenforce 1).

AppArmor (Ubuntu, Debian)#

1. Verifique se existem perfis ativos para o SSH no AppArmor:

   sudo aa-status | grep sshd

Se o perfil do sshd estiver ativo e em modo enforcing, certifique-se de que as permissões locais em usr.sbin.sshd não estão bloqueando portas alternativas ou recarregue o perfil caso aplique alguma alteração.

Passo 3: Liberação de portas no firewall local (antes da mudança)#

Você deve instruir o firewall local a aceitar tráfego de entrada na nova porta SSH antes de reiniciar o daemon.

Opção a: configuração via UFW (uncomplicated firewall)#

1. Permita conexões de entrada TCP na nova porta:

   sudo ufw allow 22022/tcp

1. Recarregue o firewall para aplicar as alterações:

   sudo ufw reload

1. Valide o status e certifique-se de que a nova regra está ativa na lista:

   sudo ufw status verbose

Opção b: configuração via iptables diretamente#

1. Adicione a nova regra na chain de entrada (INPUT) para o protocolo TCP na nova porta customizada:

   sudo iptables -A INPUT -p tcp --dport 22022 -j ACCEPT

1. Salve as regras de forma definitiva no sistema para que sejam persistidas pós-reboot:

   # Opção recomendada utilizando netfilter-persistent
   sudo netfilter-persistent save
   
   # Ou gravando as regras manualmente no arquivo de configuração do sistema
   sudo sh -c 'iptables-save > /etc/iptables/rules.v4'
   sudo sh -c 'ip6tables-save > /etc/iptables/rules.v6'

Passo 4: Edição do sshd_config#

O daemon do SSH é controlado pelo arquivo localizado em sshd_config.

A regra de precedência e acúmulo no openssh#

No OpenSSH, a diretiva Port é cumulativa. Ao contrário de diretivas como PermitRootLogin (onde o primeiro correspondente no topo do arquivo vence), declarar múltiplos parâmetros Port instruirá o daemon a escutar em todas as portas listadas concorrentemente.

Audite também a pasta sshd_config.d para garantir que não há includes externos ativando a porta 22:

grep -r -i "^Port" /etc/ssh/sshd_config.d/ 2>/dev/null

Se alguma linha ativa (sem o caractere #) como Port 22 for encontrada em um arquivo de include, comente-a ou remova-a.

Abra o arquivo principal sshd_config:

sudo nano /etc/ssh/sshd_config

Localize a linha #Port 22 (ou Port 22 caso já estivesse ativa), remova o caractere # e atualize o valor para a nova porta:

Port 22022

Salve e feche o arquivo (Ctrl+O, Enter, Ctrl+X). Alternativamente, execute a substituição via sed:

sudo sed -i 's/#Port 22/Port 22022/g' /etc/ssh/sshd_config

Validando a configuração efetiva parsada#

Antes de reiniciar o daemon SSH, execute um teste de sintaxe na configuração usando a flag -T. Esse comando parseia todo o arquivo de configuração e seus includes, exibindo a configuração final resultante que será aplicada:

sudo sshd -T | grep -i "port"

Garanta que a saída do comando exiba apenas port 22022. Se a porta 22 também aparecer listada, revise as configurações e imports do diretório sshd_config.d.

Passo 5: Reinicialização do daemon SSH#

Com a configuração validada e as regras de firewall ativas, reinicie o daemon SSH no sistema para que as mudanças tenham efeito:

# Reiniciar utilizando o systemctl (padrão systemd)
sudo systemctl restart sshd

Passo 6: Validação de conexão em janela paralela#

1. Abra um novo terminal em sua máquina local.
2. Tente estabelecer uma nova conexão especificando a porta com o parâmetro -p:

   ssh usuario@IP_DO_SERVIDOR -p 22022

3. Hardening SSH adicional e chaves criptográficas#

Apenas alterar a porta padrão não torna o SSH impenetrável. Para obter um nível de segurança corporativa, aplique as diretivas de hardening a seguir.

Hardening de configuração do daemon#

Edite /etc/ssh/sshd_config e adicione ou ajuste as seguintes opções para reforçar a segurança do serviço:

# Desabilitar login de root diretamente (força o uso de sudo)
PermitRootLogin no

# Desabilitar autenticação por senha convencional
PasswordAuthentication no

# Limitar o número máximo de tentativas de login inválidas por conexão
MaxAuthTries 3

# Definir tempo limite de inatividade para concluir a autenticação (em segundos)
LoginGraceTime 60

# Desativar X11 Forwarding para segurança gráfica de UI
X11Forwarding no

# Desativar redirecionamento de portas TCP genéricas (se não necessário)
AllowTcpForwarding no

# Aumentar o nível de detalhes do log para fins de auditoria
LogLevel VERBOSE

Reinicie o serviço (sudo systemctl restart sshd) após as edições.

Autenticação por chaves criptográficas (SSH keys)#

Chaves criptográficas eliminam a fragilidade de ataques brutais contra senhas de usuários.

1. Na sua máquina local (cliente), gere um par de chaves forte utilizando o algoritmo Ed25519:

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

1. Transfira a chave pública gerada para o servidor remoto especificando a porta customizada:

   ssh-copy-id -p 22022 usuario@IP_DO_SERVIDOR

1. Teste a conexão sem senha e em seguida desative permanentemente as senhas definindo PasswordAuthentication no em /etc/ssh/sshd_config.

4. Proteção adicional contra ataques: Fail2ban#

Para proteger a sua porta customizada de varreduras direcionadas, instale o fail2ban para banir IPs maliciosos que errarem senhas consecutivas.

1. Instale o serviço:

   sudo apt-get update && sudo apt-get install -y fail2ban

1. Crie um arquivo de configuração local para evitar que suas regras sejam sobrescritas em futuras atualizações:

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

1. Edite /etc/fail2ban/jail.local e configure a jail específica do SSH para escutar na nova porta customizada:

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

(Nota: Caso utilize RHEL/Rocky Linux, ajuste o parâmetro logpath para secure).

1. Reinicie o fail2ban:

   sudo systemctl restart fail2ban
   sudo systemctl enable fail2ban

5. Auditoria de logs de autenticação#

Para auditar o acesso ao SSH e certificar-se de que os eventos de conexão estão sendo logados corretamente na nova porta, monitore os logs de autenticação do sistema em tempo real enquanto efetua logins:

# Debian / Ubuntu
sudo tail -f /var/log/auth.log

# RHEL / Rocky Linux / AlmaLinux
sudo tail -f /var/log/secure

Procure por entradas registrando a porta de conexão para garantir a observabilidade de acessos: Accepted publickey for usuario from IP_ORIGEM port PORTA_ORIGEM ssh2: ED25519...

6. Procedimento de rollback de emergência#

Se o daemon do SSH falhar ao iniciar, se você for bloqueado nas novas conexões ou precisar reverter as alterações rapidamente, utilize este roteiro de rollback (com acesso físico via terminal, console de console virtual na nuvem KVM/IPMI/iLO):

1. Acesse o servidor remoto pelo console ou painel de controle da nuvem.
2. Restaure o arquivo de configuração original a partir do backup:

   sudo cp /etc/ssh/sshd_config.backup.* /etc/ssh/sshd_config

1. Se tiver criado alterações nas pastas de include, comente-as ou exclua os arquivos criados temporariamente.
2. Reinicie o daemon SSH para retornar à porta 22:

   sudo systemctl restart sshd

1. Valide que o serviço retornou à porta padrão 22:

   sudo ss -tulpn | grep ssh

1. Reconecte a partir da sua máquina local na porta 22.

7. Script de migração automatizada e segura#

Abaixo está o script shell completo e seguro para automatizar a troca de porta do SSH. O script segue estritamente a ordem de operações recomendada, faz backups preventivos, configura regras de firewall, adiciona portas no SELinux e valida as alterações antes de reiniciar o daemon SSH. Você pode inspecionar o código completo abaixo sem sair da página ou acessar a versão mantida no Gist:

#!/bin/bash
# migrate_ssh_port.sh - Altera a porta do SSH com segurança e previne lockout
# ⚠️ Deve ser executado com privilégios de root (sudo)

set -e

NEW_PORT=22022
BACKUP="/etc/ssh/sshd_config.backup.$(date +%Y%m%d-%H%M%S)"

# Cores para saída no terminal
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

log() { echo -e "${GREEN}[INFO]${NC} $1"; }
warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }
error() { echo -e "${RED}[ERROR]${NC} $1"; exit 1; }

# 1. Verificar privilégios de execução
[[ $EUID -ne 0 ]] && error "Este script deve ser executado como root (ou via sudo)"

# 2. Verificar se a nova porta já está em uso no sistema
ss -tulpn | grep -q ":${NEW_PORT} " && error "A porta ${NEW_PORT} já está em uso por outro serviço"

# 3. Criar cópia de segurança preventiva do sshd_config
log "Criando backup da configuração atual em: ${BACKUP}"
cp /etc/ssh/sshd_config "$BACKUP"

# 4. Configurar as políticas de controle de acesso do SELinux
if command -v getenforce &>/dev/null && [[ $(getenforce) == "Enforcing" ]]; then
    log "SELinux ativo (Enforcing). Adicionando a nova porta SSH às politicas de controle..."
    semanage port -a -t ssh_port_t -p tcp "$NEW_PORT" 2>/dev/null || \
    warn "A porta já pode estar configurada ou o comando semanage falhou. Verifique manualmente."
fi

# 5. Configurar o firewall local do servidor (ANTES de alterar o SSH)
log "Configurando regras do firewall local..."
if command -v ufw &>/dev/null && [[ $(sudo ufw status | grep -c "Status: active") -ge 1 ]]; then
    log "UFW detectado e ativo. Liberando porta TCP ${NEW_PORT}..."
    ufw allow "${NEW_PORT}/tcp"
    ufw reload
elif command -v iptables &>/dev/null; then
    log "Iptables detectado. Adicionando regra de INPUT para TCP ${NEW_PORT}..."
    iptables -A INPUT -p tcp --dport "$NEW_PORT" -j ACCEPT
    
    # Salvar regras de forma persistente no sistema
    if command -v netfilter-persistent &>/dev/null; then
        netfilter-persistent save
    else
        iptables-save > /etc/iptables/rules.v4 2>/dev/null || warn "Não foi possível persistir regras via iptables-save"
    fi
else
    warn "Nenhum gerenciador de firewall comum ativo (UFW/iptables) detectado. Certifique-se de liberar a porta ${NEW_PORT} na borda."
fi

# 6. Alterar a porta SSH no arquivo principal
log "Atualizando a porta no arquivo /etc/ssh/sshd_config..."
sed -i "s/#Port 22/Port ${NEW_PORT}/g" /etc/ssh/sshd_config

# 7. Alertar sobre possíveis conflitos nos includes
if grep -r -i "^Port 22" /etc/ssh/sshd_config.d/ &>/dev/null; then
    warn "Foram encontradas menções ativas à porta 22 no diretório /etc/ssh/sshd_config.d/. Certifique-se de removê-las para evitar escutas indesejadas na porta 22."
fi

# 8. Validar a sintaxe da configuração parsed efetiva
log "Validando integridade da configuração efetiva do SSH..."
sshd -T | grep -qi "port ${NEW_PORT}" || error "A validação da configuração do OpenSSH falhou. Efetue rollback com: cp ${BACKUP} /etc/ssh/sshd_config"

# 9. Reiniciar o serviço SSH
log "Reiniciando o daemon do SSH..."
systemctl restart sshd

# 10. Confirmar status final do serviço
if systemctl is-active --quiet sshd; then
    log "✅ SSH configurado e ativo com sucesso na porta ${NEW_PORT}!"
    log "📋 Socket ativo: $(ss -tulpn | grep sshd | awk '{print $4}' | tr '\n' ' ')"
    log ""
    log "⚠️  MANTENHA ESTA JANELA ABERTA E TESTE A CONEXÃO EM UM NOVO TERMINAL PARALELO:"
    log "   ssh usuario@IP_DO_SERVIDOR -p ${NEW_PORT}"
else
    error "❌ Falha ao iniciar o daemon SSH. Efetue o rollback manual utilizando o backup em: ${BACKUP}"
fi

Veja também

Cibersegurança Liberando ranges de IP do Cloudflare no CSF sem comprometer a segurança

Cibersegurança Troubleshooting real: do crash status 255 no Fail2ban ao backend systemd e modularização no Nginx

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Este post está licenciado sob CC BY-NC.