SSH known_hosts e verificação da chave do host em automação: ssh-keyscan mais uma verificação fora de banda

Objetivo

Preencher o known_hosts para um servidor ao qual um processo automatizado (um agente, um pipeline de deploy) precisa se conectar por SSH, sem deixar a conexão exposta a um ataque de machine-in-the-middle no primeiro contato e sem um prompt interativo de "yes/no" que interrompa execuções sem supervisão.

Pré-requisitos

Acesso de rede à porta SSH do host de destino; uma forma de obter a impressão digital (fingerprint) da chave do host por um canal diferente da própria conexão SSH (saída do console do provedor de nuvem, inventário da ferramenta de gerenciamento de configuração, o log de provisionamento do próprio host).

Passos

1. Colete a chave em um arquivo temporário, não diretamente no known_hosts: ssh-keyscan -H targethost > targethost.keys (adicione -p <port> para uma porta não padrão). A opção -H aplica hash ao nome do host na entrada armazenada, de modo que um arquivo vazado não revele quais hosts são considerados confiáveis. A man page avisa que um arquivo known_hosts montado com ssh-keyscan sem verificar as chaves deixa os usuários expostos a ataques de machine-in-the-middle: ele registra qualquer chave que o host apresente.
2. Verifique fora de banda e só então acrescente: ssh-keygen -lf targethost.keys mostra as impressões digitais exatamente do que foi escaneado; compare-as com uma impressão digital obtida de forma independente e, somente se coincidirem, execute cat targethost.keys >> ~/.ssh/known_hosts. Fontes independentes: o log do console da instância no provedor de nuvem, um valor registrado no momento do provisionamento ou um registro DNS SSHFP, se a zona for assinada. A RFC 4255 define o registro de recurso SSHFP justamente para isso: publicar no DNS a impressão digital da chave do host, para que o cliente possa verificá-la sem uma decisão manual prévia de confiança, e o ssh pode ser configurado para consultá-la por meio de VerifyHostKeyDNS.
3. Configure o comportamento do cliente para conexões sem supervisão no ssh_config: StrictHostKeyChecking accept-new (OpenSSH 7.6 e posteriores, documentado em ssh_config(5)) adiciona, sem perguntar, as chaves de hosts que ainda não estão no known_hosts, mas continua recusando a conexão se um host já conhecido apresentar uma chave diferente. Isso difere de StrictHostKeyChecking no, que também permite prosseguir com conexões a um host cuja chave mudou (com um aviso e algumas restrições) e que não deve ser usado em automação.
4. Defina HashKnownHosts yes (também em ssh_config(5)), para que um arquivo known_hosts que vaze ou seja commitado por engano não liste os nomes de host da infraestrutura. O padrão do upstream é no (o /etc/ssh/ssh_config distribuído por Debian/Ubuntu define yes), e a opção afeta apenas entradas adicionadas depois; ssh-keygen -H aplica hash a um arquivo já existente.

Resultado esperado

A primeira conexão a um host recém-provisionado funciona de forma não interativa depois que a chave dele foi registrada e verificada fora de banda; uma conexão posterior ao mesmo endereço, caso a chave do host mude de forma inesperada (host recriado a partir de uma imagem ou um verdadeiro machine-in-the-middle), falha de maneira explícita em vez de atualizar a chave silenciosamente.

Limites e base de verificação

O accept-new protege contra uma chave que muda depois da primeira confiança, não contra uma chave ruim aceita na primeira vez; a verificação fora de banda do passo 2 é justamente o que o passo 3 não consegue oferecer sozinho. A verificação por SSHFP é tão confiável quanto a zona DNS. VerifyHostKeyDNS tem como padrão no; quando definido como yes, o ssh_config(5) diz que chaves que correspondem a uma impressão digital segura (validada por DNSSEC) são aceitas implicitamente, enquanto impressões digitais não seguras são tratadas como se a opção fosse ask, ou seja, a resposta é apenas exibida e quem decide continua sendo o StrictHostKeyChecking. Um resultado só conta como seguro se um resolvedor com validação definir o flag AD e o cliente o aceitar; com glibc 2.31 e posteriores, isso exige options trust-ad em /etc/resolv.conf.