sshfinder

Encontre todos os serviços SSH na sua rede, avalie se eles atendem ao seu padrão e seja notificado quando isso mudar.

sshfinder é um único arquivo Python sem dependências obrigatórias. Aponte-o para um intervalo CIDR e ele descobre SSH onde quer que esteja realmente escutando — não apenas na porta 22 — confirma que cada um realmente fala SSH, avalia sua postura criptográfica e retorna um código de saída diferente de zero quando algo falha na sua política.

---

O problema que ele resolve

A maioria das equipes não consegue responder a três perguntas sobre seu próprio parque SSH:

1. Quantos serviços SSH temos e onde? Não quantas máquinas — quantos serviços SSH em escuta, incluindo aquele na porta 2222 que um contratado configurou em 2019.
2. Todos atendem ao nosso padrão? Login por senha desabilitado, sem cifras quebradas, não expostos ao Terrapin. Comprovadamente, não por afirmação.
3. O que mudou desde ontem à noite? Uma chave de host que mudou. Um serviço que apareceu. Autenticação por senha que voltou após um rebuild.

As ferramentas existentes respondem a cada parte disso e param:

Ferramenta	Descobre SSH	Avalia	Em toda a frota
nmap	sim	superficial, via scripts NSE	sim
ssh-audit	não — você fornece um host	profundamente	não
masscan / zmap	em escala de internet	não	sim
sshfinder	sim	sim	sim

Essa lacuna — descoberta e avaliação e um veredito, em um único artefato — é o que esta ferramenta existe para preencher. Se você só precisa auditar um host que já conhece, use ssh-audit; ele vai mais fundo em um único serviço do que esta ferramenta.

Para quem é

• Segurança interna e inventário de ativos. Construa e mantenha um registro de cada serviço SSH no parque, exportado para CSV ou JSON.
• Equipes de plataforma e SRE com obrigação de conformidade. Comprove, em um cronograma e com um código de saída, que nenhum host em uma VPC aceita login por senha ou oferece criptografia fraca.
• Qualquer pessoa executando uma migração pós-quântica. Um número para quanto da frota ainda não consegue negociar troca de chaves pós-quântica, e exatamente quais serviços são esses.

Testadores de penetração acharão a auditoria e o pivô SOCKS úteis, mas a ferramenta é moldada em torno de executar a mesma varredura repetidamente contra um parque que você possui, não em torno de um engajamento único.

---

Início rápido

git clone https://github.com/kabiri-labs/sshfinder.git
cd sshfinder
python sshfinder.py 10.0.0.0/24 -p 22,2222

Sem instalação, sem dependências. Requer Python 3.9+.

As três coisas que ele faz, em três comandos:

# 1. INVENTÁRIO — que SSH existe por aí?
python sshfinder.py 10.0.0.0/24 --audit --format csv -o ssh-inventory.csv

# 2. VEREDITO — atende ao nosso padrão? (sai com 3 se não)
python sshfinder.py 10.0.0.0/24 -p 22,2222 --policy baseline

# 3. DERIVA — o que mudou desde ontem à noite?
python sshfinder.py 10.0.0.0/24 -p 22,2222 --baseline yesterday.json \
    --fail-on-drift

---

1. Inventário

Escanear todas as 65535 portas é o padrão, porque um serviço SSH em uma porta não padrão é exatamente aquele que ninguém registrou. Cada porta aberta é rotulada, então uma porta aberta nunca é silenciosamente contada como uma SSH:

=== 10.0.0.5 ===
  open: 10.0.0.5:22 [SSH], 10.0.0.5:8080 [not ssh]
  SSH  10.0.0.5:22  (SSH-2.0-OpenSSH_7.4)

A confirmação é uma troca de identificação real RFC 4253, não uma olhada nos primeiros bytes no fio. Servidores que imprimem um banner legal primeiro, que esperam o cliente se identificar, ou cujo banner chega dividido entre segmentos TCP são todos reconhecidos corretamente — cada um desses é um falso negativo em uma implementação ingênua.

Adicione --audit para a visão completa de cada serviço:

  SSH  10.0.0.5:22  (SSH-2.0-OpenSSH_7.4)
       host key: ssh-ed25519 SHA256:T/ZM4jOL4amTsO5K3AaCdg2...
       auth: publickey, password  [!] password auth enabled
       [!] Terrapin (CVE-2023-48795): VULNERABLE
       [!] weak ciphers: aes128-cbc
           aes128-cbc [weak]: CBC mode is vulnerable to the SSH plaintext-recovery attack (CVE-2008-5161) and, …

Chaves de host SSH compartilhadas (possíveis hosts compartilhados/clonados):
  SHA256:T/ZM4jOL4amTsO5K3AaCdg2...
    -> 10.0.0.5:22, 10.0.0.9:22

Esse último bloco vale a pena conhecer: uma chave de host reutilizada entre máquinas geralmente significa VMs clonadas ou uma imagem compartilhada, e significa que comprometer um host compromete a identidade de todos eles.

Prontidão pós-quântica

O OpenSSH 10.0 tornou mlkem768x25519-sha256 a troca de chaves padrão, e o 10.1 avisa que sessões clássicas estão abertas à captura armazene agora, descriptografe depois. --pq-report responde à pergunta no nível da frota diretamente, usando apenas o KEXINIT — então não precisa de biblioteca de terceiros:

python sshfinder.py 10.0.0.0/24 -p 22,2222 --pq-report

Post-quantum readiness:
  1/3 service(s) negotiate post-quantum key exchange with a current client
  [!] no PQ key exchange offered (1):
        10.0.0.2:22
  [!] pre-standard PQ only (1) - looks post-quantum but is not:
        10.0.0.3:22
  2 service(s) exposed to store-now-decrypt-later capture; upgrade to OpenSSH 9.0+

A categoria pre-standard é a que pega as pessoas de surpresa. Um servidor anunciando [email protected] ou um rascunho Kyber parece pós-quântico em um despejo de algoritmos, mas o OpenSSH descartou esse conjunto de parâmetros retirado em 2020 — então um cliente atual não encontra método comum e cai de volta para criptografia clássica. Contado como pronto, seria pior do que não olhar nada.

2. Veredito

Um relatório descreve um problema. Uma política afirma um, e pode falhar um build:

python sshfinder.py 10.0.0.0/24 -p 22,2222 --policy baseline; echo "exit $?"

Policy 'baseline':
  No password login, no Terrapin exposure, no weak algorithms.
  1/3 service(s) pass
  [FAIL] 1 service(s):
        10.0.0.3:22
          - password_auth: password login accepted: publickey, password
          - terrapin: vulnerable to Terrapin (CVE-2023-48795)
          - post_quantum (warn): post-quantum readiness is absent, ready required
  [warn] 1 service(s):
        10.0.0.2:22
          - post_quantum (warn): post-quantum readiness is absent, ready required
exit 3

Três políticas vêm embutidas — baseline, strict e pq — nomeadas pelo resultado que impõem, não por uma distribuição. Regras carregam uma severidade fail ou warn e --fail-on decide quais portões, então uma equipe pode adotar um padrão mais rígido como aviso primeiro e promovê-lo depois sem editar nada.

Escreva a sua própria como JSON:

{
  "name": "house-rules",
  "description": "What we expect of every SSH service.",
  "rules": [
    {"check": "password_auth", "severity": "fail"},
    {"check": "terrapin", "severity": "fail"},
    {"check": "post_quantum", "require": "ready", "severity": "warn"},
    {"check": "forbid", "field": "ciphers",
     "algorithms": ["3des-cbc", "arcfour"], "severity": "fail"},
    {"check": "require", "field": "kex_algorithms",
     "algorithms": ["curve25519-sha256"], "severity": "fail"}
  ]
}

Verificações: password_auth, terrapin, weak_algorithms, post_quantum (com require: ready, legacy ou absent), e forbid / require sobre um field de kex_algorithms, host_key_algorithms, ciphers ou macs.