Hardening de SSH no Linux: Guia Completo com OpenSSH 10, Criptografia Pós-Quântica e MFA

Introdução: O SSH Ainda É o Alvo Número 1

Se o seu servidor Linux tá exposto na internet, pode ter certeza: alguém já tentou entrar nele via SSH hoje. Sério, provavelmente enquanto você lê isso. Os dados de 2025 mostram que ataques de força bruta contra SSH representam 89% de todos os comportamentos de ataque em endpoints Linux. E o cenário não dá sinais de melhora — no Q4 de 2025, o worm P2PInfect sozinho respondeu por 80,4% de todo o malware direcionado a servidores SSH Linux. No início de 2026, o botnet SSHStalker já havia comprometido pelo menos 7.000 servidores — metade nos Estados Unidos — usando exclusivamente força bruta contra autenticação por senha.

A mensagem é bem direta: se você ainda permite login por senha no SSH em 2026, está basicamente convidando botnets pra um café.

A boa notícia? O OpenSSH 10.0, lançado em abril de 2025, trouxe mudanças que realmente fazem diferença: criptografia pós-quântica como padrão, remoção completa do DSA e uma nova arquitetura que separa a fase de pré-autenticação em um binário dedicado. Então, vamos aproveitar tudo isso neste guia — e ir além, cobrindo desde a configuração base até autenticação multifator, certificados SSH e integração com ferramentas de defesa.

O Que Mudou no OpenSSH 10.0

Antes de mergulhar na configuração, vale entender o que o OpenSSH 10.0 trouxe de novo. São mudanças que impactam diretamente como você configura e protege o SSH no dia a dia.

Criptografia Pós-Quântica como Padrão

O OpenSSH já oferece troca de chaves pós-quântica desde a versão 9.0 (lá em abril de 2022), inicialmente via sntrup761x25519-sha512. Na versão 9.9, o algoritmo híbrido mlkem768x25519-sha256 foi adicionado — e no OpenSSH 10.0, ele se tornou o padrão para troca de chaves.

Esse algoritmo combina o X25519 ECDH com o ML-KEM (baseado no CRYSTALS-Kyber, padronizado pelo NIST no FIPS 203), garantindo proteção contra ataques clássicos e contra futuros computadores quânticos. Parece coisa de ficção científica, mas é uma preocupação real — e já está no padrão.

Na prática: se você atualizar para o OpenSSH 10.0 e não alterar nada, suas conexões já estarão protegidas contra o cenário "harvest now, decrypt later" — onde atacantes capturam tráfego cifrado hoje pra descriptografar quando tiverem acesso a computadores quânticos no futuro.

Remoção Completa do DSA

O DSA já estava deprecated há uma década. No OpenSSH 9.9, foi desabilitado em tempo de compilação. No 10.0? Suporte completamente removido.

Se você ainda tem chaves DSA nos seus servidores, é hora de migrá-las — elas simplesmente não funcionam mais.

Separação do sshd-auth

Essa mudança é mais sutil, mas importante: a fase de autenticação do daemon SSH agora roda em um binário separado chamado sshd-auth. Isso reduz a superfície de ataque na pré-autenticação, isolando o código que processa credenciais antes do login ser concluído. Uma mudança arquitetural que melhora a segurança sem exigir nenhuma configuração adicional da sua parte.

Aviso de Criptografia Fraca no 10.1

E olhando pra frente: o OpenSSH 10.1 (lançado no final de 2025) passou a exibir um aviso quando a conexão negocia um algoritmo de troca de chaves que não é pós-quântico. A diretiva WarnWeakCrypto no ssh_config permite desabilitar esse aviso, mas, honestamente, a recomendação é deixá-lo ativo. Se algo te incomoda, é porque provavelmente precisa ser corrigido.

Configuração Base: sshd_config Hardened

O coração do hardening SSH é o arquivo /etc/ssh/sshd_config. A configuração padrão do OpenSSH é feita pra funcionar "out of the box" — e não pra ser segura em produção. Vamos corrigir isso.

Configuração Completa para Produção

Aqui vai uma configuração completa e comentada. Cada diretiva tem um propósito específico, e eu recomendo ler os comentários pra entender o que cada uma faz antes de simplesmente copiar e colar:

# /etc/ssh/sshd_config — Configuração Hardened para Produção
# Testado com OpenSSH 10.0+ em Ubuntu 24.04 / Debian 12 / RHEL 9

# ============================================
# REDE E PROTOCOLO
# ============================================

# Porta personalizada (reduz ruído de bots automatizados)
Port 2222

# Escutar apenas em interfaces necessárias
# Substitua pelo IP do seu servidor
ListenAddress 0.0.0.0
AddressFamily inet

# Protocolo SSH versão 2 apenas (default desde OpenSSH 7.4)
# Protocol 2 — já é o único suportado, não precisa declarar

# ============================================
# AUTENTICAÇÃO
# ============================================

# Desabilitar login direto como root — CRÍTICO
PermitRootLogin no

# Desabilitar autenticação por senha — CRÍTICO
PasswordAuthentication no

# Desabilitar senhas vazias
PermitEmptyPasswords no

# Habilitar autenticação por chave pública
PubkeyAuthentication yes

# Desabilitar autenticação baseada em host
HostbasedAuthentication no

# Desabilitar autenticação interativa por teclado
# (reabilitar se usar MFA/TOTP — veja seção específica)
KbdInteractiveAuthentication no

# Limite de tentativas de autenticação (CIS recomenda 4 ou menos)
MaxAuthTries 3

# Limite de sessões simultâneas por conexão
MaxSessions 3

# Tempo máximo para completar a autenticação
LoginGraceTime 30

# Restringir acesso a grupos específicos
AllowGroups ssh-users

# ============================================
# ALGORITMOS E CIFRAS
# ============================================

# Algoritmos de troca de chaves (pós-quânticos primeiro)
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

# Cifras simétricas (256-bit primeiro para resistência quântica)
Ciphers [email protected],[email protected],aes256-ctr

# MACs (Message Authentication Codes)
MACs [email protected],[email protected]

# Algoritmos de chave do host
HostKeyAlgorithms ssh-ed25519,[email protected],rsa-sha2-512,rsa-sha2-256

# Tamanho mínimo de chave RSA (3072 bits para resistência quântica)
RequiredRSASize 3072

# ============================================
# SESSÃO E TIMEOUT
# ============================================

# Verificação de cliente ativo (desconectar sessões idle)
# 300 segundos * 3 verificações = 15 min de inatividade máxima
ClientAliveInterval 300
ClientAliveCountMax 3

# Desabilitar forwarding desnecessário
AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no

# Desabilitar tunneling
PermitTunnel no

# ============================================
# LOGGING E AUDITORIA
# ============================================

# Nível de log detalhado para auditoria
LogLevel VERBOSE

# Facility para syslog
SyslogFacility AUTH

# Exibir banner de aviso legal
Banner /etc/ssh/banner

# Exibir data/hora do último login
PrintLastLog yes

# ============================================
# PROTEÇÕES ADICIONAIS
# ============================================

# Verificar permissões dos arquivos do usuário
StrictModes yes

# Usar separação de privilégios (default desde OpenSSH 7.5)
# Agora reforçado com sshd-auth no OpenSSH 10.0

# Número máximo de conexões não autenticadas simultâneas
MaxStartups 10:30:60

# Desabilitar GSSAPI (a menos que use Kerberos)
GSSAPIAuthentication no

# Desabilitar ambiente do usuário
PermitUserEnvironment no

# Aceitar apenas variáveis de ambiente seguras
AcceptEnv LANG LC_*

Importante: antes de aplicar essa configuração num servidor remoto, mantenha uma sessão SSH aberta como backup e teste com sudo sshd -T para verificar a configuração efetiva. Já vi gente se trancar pra fora do próprio servidor por pular esse passo — não seja essa pessoa. Depois reinicie o serviço:

# Testar configuração antes de aplicar
sudo sshd -T

# Reiniciar o serviço (NÃO mata sessões ativas)
sudo systemctl restart sshd

# Verificar status
sudo systemctl status sshd

Criando o Grupo ssh-users

A diretiva AllowGroups ssh-users restringe o acesso SSH apenas a membros desse grupo. É uma das formas mais simples e eficientes de controlar quem pode se conectar. Crie o grupo e adicione os usuários autorizados:

# Criar o grupo
sudo groupadd ssh-users

# Adicionar usuários ao grupo
sudo usermod -aG ssh-users seu_usuario

# Verificar membros do grupo
getent group ssh-users

Autenticação com Chaves Ed25519

O Ed25519 é o algoritmo recomendado para chaves SSH em 2026. Ele gera chaves compactas de 256 bits com segurança equivalente a RSA-3072, mas com geração e verificação significativamente mais rápidas. A implementação também é mais simples e menos vulnerável a ataques de canal lateral.

Resumindo: é melhor em praticamente tudo. Use Ed25519.

Gerando e Implantando a Chave

# Gerar chave Ed25519 com 100 rounds de KDF (proteção contra brute-force)
ssh-keygen -t ed25519 -a 100 -C "admin@meuservidor-2026" -f ~/.ssh/id_ed25519

# Copiar a chave pública para o servidor
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 usuario@servidor

# Ou manualmente:
cat ~/.ssh/id_ed25519.pub | ssh -p 2222 usuario@servidor \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Protegendo a Chave Privada

# Verificar permissões corretas
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# Adicionar passphrase a uma chave existente (se esqueceu de definir)
ssh-keygen -p -f ~/.ssh/id_ed25519

O parâmetro -a 100 na geração da chave define 100 rounds de derivação de chave (KDF). Isso torna a chave privada significativamente mais resistente a ataques de força bruta caso o arquivo seja comprometido — com um custo mínimo de tempo na geração, menos de 1 segundo em hardware moderno. É o tipo de configuração que não custa quase nada e pode salvar você de uma dor de cabeça enorme.

Configuração do Cliente SSH

Configure o arquivo ~/.ssh/config para simplificar conexões e forçar boas práticas. Eu pessoalmente considero esse arquivo um dos mais subutilizados — a maioria dos admins digita o comando completo toda vez:

# ~/.ssh/config

# Configurações globais
Host *
    # Preferir algoritmos pós-quânticos
    KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256
    # Usar apenas Ed25519 por padrão
    IdentityFile ~/.ssh/id_ed25519
    # Reusar conexões (performance)
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600
    # Verificar chave do host
    StrictHostKeyChecking ask
    # Enviar keep-alive para evitar desconexão
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Exemplo: servidor de produção
Host producao
    HostName 192.168.1.100
    Port 2222
    User deploy
    IdentityFile ~/.ssh/id_ed25519_producao

# Criar diretório para sockets de conexão
mkdir -p ~/.ssh/sockets

Criptografia Pós-Quântica na Prática

Com o OpenSSH 10.0, a criptografia pós-quântica já vem ativada por padrão. Mas vale entender o que isso significa na prática e, mais importante, como verificar se está funcionando.

Verificando o Algoritmo de Troca de Chaves

# Conectar com verbose para ver o algoritmo negociado
ssh -vv -p 2222 usuario@servidor 2>&1 | grep "kex:"

# Saída esperada com OpenSSH 10.0+:
# debug1: kex: algorithm: mlkem768x25519-sha256

Se a saída mostrar mlkem768x25519-sha256, sua conexão já está protegida contra ataques quânticos. O crescimento da adoção desse algoritmo foi de 554% entre outubro de 2024 e março de 2025.

Ainda assim, a realidade é que três quartos das versões do OpenSSH expostas na internet ainda rodam versões entre 2015 e 2022, sem suporte a criptografia pós-quântica. Se o seu servidor é um desses, vale a pena priorizar essa atualização.

Forçando Algoritmos Pós-Quânticos no Servidor

Se quiser garantir que todas as conexões usem troca de chaves pós-quântica (rejeitando clientes antigos), configure no sshd_config:

# Aceitar APENAS troca de chaves pós-quântica
KexAlgorithms mlkem768x25519-sha256,[email protected]

Cuidado: isso vai impedir conexões de clientes com OpenSSH anterior ao 9.0. Avalie se todos os seus clientes suportam antes de aplicar — especialmente se você tem scripts automatizados ou ferramentas de CI/CD que conectam via SSH.

Autenticação Multifator (MFA) com TOTP

Autenticação por chave pública é excelente — mas e se a chave privada for comprometida? Notebook roubado, backup vazado, um colega que copiou a chave pra um pen drive "só pra facilitar"... acontece mais do que a gente gostaria de admitir.

A autenticação multifator resolve isso adicionando uma segunda camada: além de possuir a chave, o usuário precisa provar que tem acesso a um dispositivo físico (celular com app autenticador).

Instalação do Google Authenticator PAM

# Ubuntu / Debian
sudo apt update && sudo apt install -y libpam-google-authenticator

# RHEL / AlmaLinux / Rocky Linux
sudo dnf install -y epel-release
sudo dnf install -y google-authenticator

Configuração por Usuário

Cada usuário que precisa de MFA deve executar a configuração individualmente:

# Execute como o usuário (NÃO como root)
google-authenticator

# Responda às perguntas:
# - Tokens baseados em tempo (TOTP)? → y
# - Atualizar o arquivo .google_authenticator? → y
# - Proibir uso múltiplo do mesmo token? → y
# - Aumentar janela de tempo? → n (manter padrão de 30s)
# - Habilitar rate limiting? → y

Um QR code será exibido no terminal. Escaneie-o com o app autenticador (Google Authenticator, Authy, FreeOTP ou similar). Salve os códigos de recuperação em um local seguro — e quando digo seguro, não é num post-it no monitor. Eles são a única forma de recuperar acesso caso perca o celular.

Configuração do PAM

Edite o arquivo /etc/pam.d/sshd para integrar o módulo:

# Adicionar ao final de /etc/pam.d/sshd
# "required" = obrigatório para todos os usuários
# Use "sufficient" se quiser que o TOTP seja opcional
auth required pam_google_authenticator.so

Configuração do sshd para MFA

Agora, ajuste o sshd_config para exigir tanto a chave pública quanto o TOTP:

# Em /etc/ssh/sshd_config

# Habilitar autenticação interativa (necessário para TOTP)
KbdInteractiveAuthentication yes

# Exigir DOIS fatores: chave pública + TOTP
AuthenticationMethods publickey,keyboard-interactive

# Reiniciar o serviço SSH
sudo systemctl restart sshd

Com essa configuração, o fluxo de login fica assim: o cliente apresenta a chave Ed25519 → o servidor valida → solicita o código TOTP → o usuário digita os 6 dígitos do app → acesso concedido. Dois fatores independentes.

Dica que pode salvar seu dia: mantenha uma sessão SSH aberta durante toda a configuração do MFA. Se algo der errado (e em TI, coisas dão errado), você ainda pode corrigir pela sessão existente sem ficar trancado pra fora.

Autenticação com Certificados SSH

Pra ambientes com muitos servidores e equipes grandes, a gestão de chaves por authorized_keys rapidamente vira um pesadelo. Já tentou revogar o acesso de alguém que tinha chave em 47 servidores? Pois é.

A solução escalável é a autenticação por certificados SSH, que funciona com uma Autoridade Certificadora (CA) central assinando chaves de curta duração.

Como Funciona

O conceito é direto: uma CA assina a chave pública do usuário gerando um certificado de curta duração (por exemplo, válido por 8 horas). O servidor confia na CA, e qualquer certificado assinado por ela é aceito automaticamente — sem precisar distribuir chaves para cada servidor individualmente.

Configuração Passo a Passo

# 1. Gerar a chave da CA (fazer uma vez, guardar com segurança absoluta)
ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

# 2. Assinar a chave pública de um usuário (certificado válido por 8 horas)
ssh-keygen -s /etc/ssh/ca_user_key \
  -I "usuario@empresa" \
  -n usuario \
  -V +8h \
  ~/.ssh/id_ed25519.pub

# Isso gera o arquivo ~/.ssh/id_ed25519-cert.pub

# 3. Verificar o certificado gerado
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

# 4. No servidor: confiar na CA
# Copiar a chave PÚBLICA da CA para o servidor
sudo cp ca_user_key.pub /etc/ssh/ca_user_key.pub

# Adicionar ao sshd_config:
echo "TrustedUserCAKeys /etc/ssh/ca_user_key.pub" | sudo tee -a /etc/ssh/sshd_config

# 5. Reiniciar o SSH
sudo systemctl restart sshd

O grande benefício aqui: quando um membro da equipe sai da organização, você não precisa limpar chaves em dezenas de servidores. O certificado de curta duração simplesmente expira. E a CA pode revogar o acesso centralmente. Na minha experiência, essa abordagem reduz drasticamente o trabalho operacional em equipes com mais de 10 pessoas.

Chaves de Hardware FIDO2 e YubiKey

Pra quem quer o nível máximo de segurança, chaves de hardware FIDO2 são o caminho. O OpenSSH suporta nativamente tokens como YubiKey, SoloKey e Titan Key do Google. A chave privada literalmente nunca sai do dispositivo físico — o que torna impossível extraí-la remotamente.

# Gerar chave SSH residente no dispositivo FIDO2
# Requer toque físico no dispositivo para cada autenticação
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "admin-yubikey-2026" -f ~/.ssh/id_ed25519_sk

# -sk = Security Key (FIDO2)
# -O resident = chave armazenada no dispositivo
# -O verify-required = exige PIN + toque

# Copiar chave pública para o servidor
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub -p 2222 usuario@servidor

Com chaves FIDO2, mesmo que um atacante obtenha acesso completo à sua estação de trabalho, ele simplesmente não consegue autenticar no SSH sem o dispositivo físico e o PIN. É inconveniente? Um pouco. Mas pra acessos críticos (servidores de produção, infraestrutura financeira), vale cada segundo extra.

Proteção com Fail2Ban e nftables

Mesmo com autenticação por chave e MFA, é fundamental implementar proteções na camada de rede. Bots não sabem que você desabilitou senha — eles vão continuar tentando, consumindo recursos e poluindo seus logs.

Configuração do Fail2Ban para SSH

# Instalar Fail2Ban
sudo apt install -y fail2ban    # Debian/Ubuntu
sudo dnf install -y fail2ban    # RHEL/AlmaLinux

# Criar configuração personalizada (não edite jail.conf diretamente)
sudo tee /etc/fail2ban/jail.local << EOF
[sshd]
enabled = true
port = 2222
filter = sshd
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables-multiport
banaction_allports = nftables-allports

# Ban progressivo: reincidentes são banidos por mais tempo
[sshd-aggressive]
enabled = true
port = 2222
filter = sshd[mode=aggressive]
backend = systemd
maxretry = 1
findtime = 86400
bantime = 604800
banaction = nftables-multiport
EOF

# Habilitar e iniciar
sudo systemctl enable --now fail2ban

# Verificar status
sudo fail2ban-client status sshd

Regras nftables para SSH

Complementando o Fail2Ban, configure regras nftables com rate limiting nativo. Essa combinação funciona muito bem — o nftables bloqueia no nível do kernel (rápido), enquanto o Fail2Ban analisa logs e faz bans mais inteligentes:

# Adicionar ao seu ruleset nftables (tabela inet filter, chain input)

# Rate limiting para SSH: máximo 3 novas conexões por minuto por IP
tcp dport 2222 ct state new limit rate 3/minute accept \
    comment "SSH rate limiting"

# Bloquear após exceder o limite
tcp dport 2222 ct state new drop \
    comment "Bloquear SSH após rate limit"

Se você implementou o hardening de firewall com nftables que abordamos em nosso guia anterior, essas regras se integram diretamente na chain de input da tabela inet filter.

Bastion Hosts e ProxyJump

Em ambientes com múltiplos servidores, um bastion host (ou servidor de salto) funciona como ponto único de entrada SSH. Os servidores internos ficam completamente inacessíveis pela internet — todo acesso SSH passa pelo bastion, que é o único com a porta exposta publicamente.

É um padrão clássico, e por boas razões.

# ~/.ssh/config — Configuração com bastion host

# Bastion host (único ponto de entrada público)
Host bastion
    HostName bastion.empresa.com.br
    Port 2222
    User admin
    IdentityFile ~/.ssh/id_ed25519

# Servidor de aplicação (acesso via bastion)
Host app-server
    HostName 10.0.1.10
    Port 22
    User deploy
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_deploy

# Servidor de banco de dados (acesso via bastion)
Host db-server
    HostName 10.0.2.20
    Port 22
    User dba
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_dba

# Agora basta conectar diretamente — o ProxyJump cuida do resto
ssh app-server

# Ou copiar arquivos via SCP passando pelo bastion automaticamente
scp arquivo.tar.gz app-server:/opt/deploys/

Com essa arquitetura, o firewall dos servidores internos pode bloquear todo tráfego SSH de entrada exceto do IP do bastion. A superfície de ataque é reduzida drasticamente — e como bônus, todo acesso fica centralizado e fácil de auditar.

Auditoria e Monitoramento de SSH

Hardening sem monitoramento é como trancar a porta e jogar fora a câmera de segurança. Você precisa saber quem está tentando entrar — e quem conseguiu.

Regras de Auditoria com Auditd

# /etc/audit/rules.d/ssh.rules

# Monitorar alterações na configuração do SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
-w /etc/ssh/ -p wa -k ssh_config_dir

# Monitorar o uso de SSH e tentativas de login
-w /usr/sbin/sshd -p x -k sshd_execution

# Monitorar alterações em chaves autorizadas
-w /root/.ssh/authorized_keys -p wa -k ssh_authorized_keys
-w /home/ -p wa -k ssh_user_keys

# Carregar regras
sudo augenrules --load

Monitoramento com Journalctl

# Verificar tentativas de login falhas em tempo real
sudo journalctl -u sshd -f | grep -i "failed\|invalid\|refused"

# Listar os IPs com mais tentativas de login hoje
sudo journalctl -u sshd --since today | grep "Failed" | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

# Verificar logins bem-sucedidos
sudo journalctl -u sshd --since today | grep "Accepted"

Se você já tem o Wazuh configurado (como abordamos no nosso guia de detecção de intrusões), ele automaticamente coleta e correlaciona eventos SSH, gerando alertas pra padrões suspeitos como múltiplas tentativas falhas, logins de IPs incomuns ou acessos fora do horário habitual.

Script de Verificação de Hardening

Pra facilitar a auditoria no dia a dia, aqui está um script que verifica os pontos críticos do hardening SSH. Eu costumo rodar isso após qualquer alteração no sshd_config — leva segundos e evita surpresas:

#!/bin/bash
# ssh_audit.sh — Verificação rápida de hardening SSH
# Uso: sudo bash ssh_audit.sh

echo "=== Auditoria de Hardening SSH ==="
echo ""

CONFIG="/etc/ssh/sshd_config"
PASS=0
FAIL=0

check() {
    local desc="$1"
    local result="$2"
    if [ "$result" = "OK" ]; then
        echo "[OK]   $desc"
        ((PASS++))
    else
        echo "[FAIL] $desc — $result"
        ((FAIL++))
    fi
}

# Verificar versão do OpenSSH
VERSION=$(ssh -V 2>&1 | grep -oP 'OpenSSH_\K[0-9]+\.[0-9]+')
if awk "BEGIN {exit !($VERSION >= 10.0)}"; then
    check "OpenSSH >= 10.0" "OK"
else
    check "OpenSSH >= 10.0" "Versão atual: $VERSION"
fi

# Verificar configurações críticas via sshd -T
EFFECTIVE=$(sudo sshd -T 2>/dev/null)

# PermitRootLogin
VAL=$(echo "$EFFECTIVE" | grep "^permitrootlogin " | awk '{print $2}')
[ "$VAL" = "no" ] && check "PermitRootLogin no" "OK" || check "PermitRootLogin no" "Atual: $VAL"

# PasswordAuthentication
VAL=$(echo "$EFFECTIVE" | grep "^passwordauthentication " | awk '{print $2}')
[ "$VAL" = "no" ] && check "PasswordAuthentication no" "OK" || check "PasswordAuthentication no" "Atual: $VAL"

# MaxAuthTries
VAL=$(echo "$EFFECTIVE" | grep "^maxauthtries " | awk '{print $2}')
[ "$VAL" -le 4 ] 2>/dev/null && check "MaxAuthTries <= 4" "OK" || check "MaxAuthTries <= 4" "Atual: $VAL"

# LogLevel
VAL=$(echo "$EFFECTIVE" | grep "^loglevel " | awk '{print $2}')
[ "$VAL" = "VERBOSE" ] && check "LogLevel VERBOSE" "OK" || check "LogLevel VERBOSE" "Atual: $VAL"

# X11Forwarding
VAL=$(echo "$EFFECTIVE" | grep "^x11forwarding " | awk '{print $2}')
[ "$VAL" = "no" ] && check "X11Forwarding no" "OK" || check "X11Forwarding no" "Atual: $VAL"

echo ""
echo "=== Resultado: $PASS OK / $FAIL FALHAS ==="

Perguntas Frequentes (FAQ)

Mudar a porta do SSH realmente melhora a segurança?

Sozinha, não. Mudar a porta é "segurança por obscuridade" e não impede um atacante determinado — ferramentas como Nmap encontram portas SSH alternativas em segundos. No entanto, como parte de uma defesa em profundidade, reduz significativamente o ruído de bots automatizados que varrem exclusivamente a porta 22. Menos ruído nos logs significa que ameaças reais ficam mais fáceis de identificar.

Ed25519 ou RSA: qual tipo de chave SSH devo usar?

Ed25519, sem dúvida. Gera chaves compactas de 256 bits com segurança equivalente a RSA-3072, é mais rápido na geração e verificação, e tem implementação mais resistente a ataques de canal lateral. Use RSA-4096 apenas quando precisar de compatibilidade com sistemas legados que não suportam Ed25519 (e faça um plano pra migrar esses sistemas).

Preciso do Fail2Ban se já uso autenticação por chave?

Não é estritamente necessário, mas vale a pena. Mesmo com login por senha desabilitado, bots continuam tentando conectar e consumindo recursos do servidor. O Fail2Ban bloqueia esses IPs, reduz a carga e limpa os logs — facilitando a identificação de ameaças reais no meio do barulho.

O que é criptografia pós-quântica no SSH e por que me importar?

Computadores quânticos suficientemente poderosos poderão quebrar algoritmos clássicos como RSA e ECDH. A ameaça concreta hoje é o ataque "harvest now, decrypt later": atacantes capturam tráfego cifrado agora para descriptografá-lo no futuro com computadores quânticos. O OpenSSH 10.0 usa por padrão o algoritmo híbrido mlkem768x25519-sha256, que combina criptografia clássica com pós-quântica pra proteger contra esse cenário.

Como configurar MFA sem risco de ficar trancado fora do servidor?

A regra de ouro: nunca feche sua sessão SSH atual durante a configuração do MFA. Mantenha pelo menos uma sessão ativa como "seguro". Salve os códigos de recuperação do Google Authenticator num local seguro (gerenciador de senhas, por exemplo). E pra ambientes críticos, garanta acesso via console físico ou IPMI/iLO/iDRAC como plano B.