24 out 2026 · seguranca, ssh, linux · 4 min

Como endurecer o SSH: o que desligar e o que manter

A maioria dos servidores SSH nasce com senha habilitada, root logando e encaminhamento de X11 ligado. Desligar essas três coisas e exigir chave pública resolve a maior parte dos ataques automatizados. O resto é ajuste fino de limites e cifras.

O que desligar

PasswordAuthentication no remove o caminho mais atacado. Força bruta em senha é o que enche o log de tentativas. Sem senha, o atacante precisa ter a chave privada, o que muda o jogo.

PermitRootLogin no impede login direto como root. Mesmo com chave, root não entra. Quem precisa de privilégio entra como usuário normal e usa sudo.

X11Forwarding no desliga o túnel de interface gráfica. Quase ninguém usa, e é superfície de ataque extra.

AllowTcpForwarding no e AllowAgentForwarding no fecham os túneis TCP e o repasse do agente SSH. Se você usa túnel para banco de dados ou para acessar um serviço interno, mantenha AllowTcpForwarding yes em um bloco Match para o usuário ou host que precisa.

ClientAliveInterval 300 com ClientAliveCountMax 2 derruba sessões inativas em dez minutos. Evita terminal aberto esquecido.

O que manter

PubkeyAuthentication yes é o que sobra. É o método que você quer.

AuthenticationMethods publickey diz que só chave pública vale. Sem fallback para senha.

UsePAM yes mantém o PAM ativo. Necessário para segundo fator via PAM, como Google Authenticator ou Duo.

Subsystem sftp fica. Desligar quebra clientes que usam SFTP e ferramentas como rsync sobre SSH.

StrictModes yes verifica permissões dos arquivos de chave. Já é padrão, mas explícito não custa.

LogLevel VERBOSE registra a chave usada em cada login. Ajuda a auditar quem entrou e quando, sem expor dados sensíveis.

O artefato

Crie o arquivo /etc/ssh/sshd_config.d/99-hardening.conf. O OpenSSH lê tudo em sshd_config.d na ordem alfabética, e a primeira ocorrência de uma diretiva vence.

# gera o arquivo de hardening do SSH (rode e confira antes de aplicar)
mkdir -p /tmp/ssh-hardening
cat > /tmp/ssh-hardening/99-hardening.conf <<'EOF'
# endurecimento de ssh: o que desligar e o que manter

# autenticacao
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30

# sessao
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
AllowStreamLocalForwarding no
PermitTunnel no
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# limites
MaxSessions 4
MaxStartups 10:30:100

# miscelanea
UseDNS no
PrintMotd no
PrintLastLog yes
Banner none

# manter o sftp
Subsystem sftp /usr/lib/openssh/sftp-server
EOF
echo "arquivo gerado:"
wc -l /tmp/ssh-hardening/99-hardening.conf
echo "--- conteudo ---"
cat /tmp/ssh-hardening/99-hardening.conf

Aplique sem derrubar a sessão atual:

sudo sshd -t && sudo systemctl reload ssh

O sshd -t valida sintaxe. Se passar, o reload aplica sem fechar conexões abertas.

Como verificar

Confirme a política efetiva:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication|authenticationmethods|maxauthtries|logingracetime|x11forwarding|allowtcpforwarding|allowagentforwarding|clientaliveinterval|clientalivecountmax|tcpkeepalive|maxsessions|maxstartups|usedns|subsystem)'

Saída esperada, com os valores que você definiu:

permitrootlogin no
passwordauthentication no
kbdinteractiveauthentication no
pubkeyauthentication yes
authenticationmethods publickey
maxauthtries 3
logingracetime 30
x11forwarding no
allowtcpforwarding no
allowagentforwarding no
clientaliveinterval 300
clientalivecountmax 2
tcpkeepalive no
maxsessions 4
maxstartups 10:30:100
usedns no
subsystem sftp /usr/lib/openssh/sftp-server

Abra outra janela e teste o login por chave antes de fechar a atual.

Se der errado

Permission denied (publickey) logo após aplicar. Causa: a chave pública não está em ~/.ssh/authorized_keys do usuário, ou as permissões estão erradas. Correção: chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys, e confirme que o arquivo tem a chave. Volte a senha temporariamente com PasswordAuthentication yes em um bloco Match para o seu IP.

sshd -t acusa Deprecated option ou Bad configuration. Causa: diretiva inexistente na versão instalada, como Protocol 2 em OpenSSH 9.x, que não existe mais. Correção: remova a linha; o padrão já é o certo.

SFTP parou de funcionar. Causa: a linha Subsystem sftp foi removida ou aponta para caminho inexistente. Correção: confirme que /usr/lib/openssh/sftp-server existe e mantenha a linha.

Antes e depois

FAQ

Preciso trocar a porta do SSH? Não. Mudar a porta reduz ruído no log, mas não é segurança. Quem escaneia encontra a porta em segundos. Mantenha 22 e invista em chave e fail2ban.

E se eu perder a chave privada? Você perde o acesso. Por isso mantenha uma segunda chave em outro lugar, ou acesso de console via provedor. Não desligue a senha antes de ter duas formas de entrar.

Funciona com chaves ed25519 e rsa? Sim. O SSH aceita os dois. Prefira ed25519 para chaves novas: ssh-keygen -t ed25519.

O reload derruba minha sessão? Não. systemctl reload ssh recarrega a configuração para novas conexões. Sessões abertas continuam.

Posso restringir por usuário ou IP? Sim. Use blocos Match no final do arquivo. Exemplo: Match User deploy seguido de AllowTcpForwarding yes libera túnel só para esse usuário. A ordem importa: Match vale até o próximo Match ou fim de arquivo.

Fontes

Documentação oficial do sshd_config: man.openbsd.org/sshd_config.

OpenSSH 9.6, manual de sshd_config: https://man.openbsd.org/sshd_config Documentação do OpenSSH: https://www.openssh.com/manual.html

Links internos: veja chave SSH em vez de senha, agente SSH e fail2ban sem se trancar fora.