Gerador de Linhas ~/.ssh/known_hosts

known_hosts e o problema do trust-on-first-use

Toda vez que o SSH conecta num servidor ele pergunta: "é a mesma máquina com quem falei da última vez?" A resposta vive em ~/.ssh/known_hosts, um arquivo com uma linha por servidor que fixa a chave pública do host. Se a chave que o servidor apresenta bate com a linha, a conexão segue em silêncio; se não, o OpenSSH recusa com o aviso berrante "REMOTE HOST IDENTIFICATION HAS CHANGED!". Essa única verificação é o que impede um man-in-the-middle de se intrometer entre seu notebook e um servidor confiável ainda servindo TCP válido — sem o pinning, o atacante apenas apresenta a própria chave e captura sua sessão.

Formato do arquivo

Cada linha não-hasheada tem três ou quatro campos separados por espaço:

github.com,140.82.114.3 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkV...
[gitlab.example.com]:2222 ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...

O host pode ser hostname, IP ou ambos separados por vírgula. Portas não-padrão usam o formato com colchetes [host]:porta. O tipo de chave (ssh-ed25519, ssh-rsa, ecdsa-sha2-nistp256 etc.) vem antes do blob base64 da chave pública. Um mesmo servidor pode ter várias linhas, uma por tipo — o OpenSSH escolhe a mais forte que combina.

Hostname hasheado para privacidade

O OpenSSH moderno usa HashKnownHosts yes por padrão: o hostname é trocado por um blob |1|sal|HMAC-SHA1 para que um atacante que roube o arquivo não consiga enumerar os servidores que você frequenta. Converta um arquivo existente com ssh-keygen -H. A consulta continua funcionando porque o SSH hashea o host de destino com o mesmo sal e compara. Para remover uma entrada antiga, use ssh-keygen -R hostname, que lida com formato puro ou hasheado.

Risco da primeira conexão e como mitigar

O TOFU só é seguro até onde o primeiro contato for. Se a primeira conexão já tiver um MITM, você felizmente pina a chave do atacante para sempre. Mitigações, em ordem de força:

• Verifique fora-de-banda — compare o fingerprint exibido pelo SSH com o que o provedor publica. O GitHub mantém o dele em docs.github.com/.../githubs-ssh-key-fingerprints.
• SSHFP no DNS — configure VerifyHostKeyDNS yes e o servidor publica seu fingerprint em registros SSHFP assinados por DNSSEC.
• Pré-distribua o arquivo via gestão de configuração (Ansible, Puppet, Chef) ou um /etc/ssh/ssh_known_hosts global.
• Certificados SSH — uma CA assina chaves de host e de usuário; clientes confiam na CA, não em fingerprints individuais. HashiCorp Vault SSH, Teleport, Smallstep e BastionZero fazem isso.

Fingerprints: SHA-256 vs MD5

Quando o SSH pede para você aceitar um host novo ele mostra algo como SHA256:dGhpc2lzbm90YXJlYWxoYXNo. O formato moderno é SHA-256 codificado em base64; o antigo MD5 com dois pontos (16:27:ac:a5:...) sumiu desde o OpenSSH 6.8 (2015). Para calcular você mesmo: ssh-keygen -lf /caminho/para/chave.pub. Para buscar uma entrada sem revelar o resto: ssh-keygen -F github.com.

Perguntas frequentes

Posso editar known_hosts à mão? Pode — é texto puro. Acrescente uma linha no formato correto e o SSH já reconhece. Remova com ssh-keygen -R hostname se estiver hasheado.

Por que o hostname é um hash ilegível? Privacidade. O hash impede que um atacante que leia o arquivo (malware, backup vazado) liste todo servidor que você acessa.

Vi um fingerprint estranho na primeira conexão — aceitar? Verifique fora-de-banda primeiro. Compare contra o valor publicado pelo provedor ou contra um registro SSHFP no DNS. Discrepância em servidor já pinado é parada obrigatória — investigue antes de forçar.

E se a chave do host mudar legitimamente? Reconstrução ou rotação. Rode ssh-keygen -R host, reconecte, confirme o fingerprint novo contra uma fonte autoritativa e deixe o SSH pinar de novo.

Existe alternativa para frotas grandes? Certificados SSH. Uma CA assina chaves de servidor, clientes só confiam na CA — sem known_hosts por host para manter.