OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
⌁

Validador sshd

Revise o hardening do SSH
Entrada
Resultado1 achados
  • ✓Nenhum problema crítico detectado

Introdução

O Validador sshd lê um sshd_config colado e verifica cinco controles que mais frequentemente causam postura SSH fraca: login root, senhas vazias, autenticação por senha, tentativas de autenticação e X11 forwarding.

O objetivo não é impor uma ideologia de SSH — é expor configurações que, combinadas, determinam se um atacante consegue fazer força bruta ou se um usuário legítimo consegue se trancar para fora.

Objetivo

  • Detectar valores PermitRootLogin que permitem login root direto.
  • Detectar PermitEmptyPasswords ativo, que permite contas sem senha.
  • Avisar quando PasswordAuthentication permanecer ativa, recomendando acesso por chave.
  • Sinalizar MaxAuthTries acima de 4 e X11Forwarding ativo sem necessidade declarada.

Entradas

  • Um colar de /etc/ssh/sshd_config (ou saída de sshd -T).
  • Linhas de comentário e vazias são ignoradas; o primeiro valor de cada chave vence.

Como funciona

A ferramenta analisa cada linha em chave e valor (sem diferenciar maiúsculas), mantendo a primeira ocorrência de cada chave, como o sshd aplica seu arquivo de padrões.

Em seguida compara cada chave relevante com a expectativa endurecida: permitrootlogin deve ser no, permitemptypasswords deve ser no, passwordauthentication deve ser no, maxauthtries deve ser 4 ou menos e x11forwarding deve ser no.

Login root e senhas vazias são tratados como severidade alta porque removem as duas principais barreiras à comprometimento remoto. Os demais controles são avisos porque o valor ideal depende do seu ambiente.

Exemplo testável

Experimente — a análise roda localmente no seu navegador.

Exemplo

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 4
X11Forwarding no

Saída esperada

PermitRootLogin no — OK.
PermitEmptyPasswords no — OK.
PasswordAuthentication no — OK.
MaxAuthTries 4 — OK.
X11Forwarding no — OK.
Resultado: nenhum problema crítico detectado.

Interpretando a saída

  • Um achado alto significa que uma configuração enfraquece ativamente o sistema; corrija após confirmar seu caminho de acesso (um usuário com sudo e uma chave funcional).
  • Um aviso é uma recomendação — por exemplo, desativar a autenticação por senha só é seguro depois que o acesso por chave for verificado.
  • Sempre teste com uma segunda sessão SSH aberta antes de recarregar o sshd: systemctl reload ssh (ou service ssh reload).

Riscos

  • Desativar a autenticação por senha sem uma chave configurada pode trancar você para fora do servidor.
  • PermitRootLogin yes convida força bruta direcionada à conta mais valiosa da máquina.
  • Alterar o sshd_config sem uma segunda sessão aberta é a forma clássica de perder o acesso remoto.

Limitações

  • A ferramenta lê apenas o texto colado; ela não lê seu arquivo de configuração real.
  • Ela verifica alguns controles, não uma auditoria completa de SSH.
  • Não consegue detectar métodos de autenticação mal configurados, host keys fracas ou problemas de agent SSH.

Referências oficiais

FAQ

Desativar a autenticação por senha é sempre correto?

Para servidores expostos à internet, quase sempre — mas somente depois de verificar o login por chave em uma segunda sessão. Em alguns ambientes gerenciados, você pode precisar manter a autenticação por senha para um bastion.

Qual é um valor seguro de MaxAuthTries?

A CIS recomenda 4 ou menos. Valores menores desaceleram a força bruta, mas podem incomodar usuários legítimos com agents mal configurados.

A ferramenta usa meu sshd_config real?

Não — apenas o texto que você cola. A fonte real é /etc/ssh/sshd_config mais os arquivos em /etc/ssh/sshd_config.d/, que você pode combinar com sshd -T.