Ansible: confira a identidade do host antes de liberar o job
O aceite de uma automação precisa identificar o destino que ela está autorizada a administrar. Propomos um roteiro para ligar essa autorização ao ambiente que realmente executa cada job.
Read in EnglishPor Pentesty
Entenda a condição descrita antes de classificar o ambiente
A Red Hat descreve em ansible-pylibssh e no plugin libssh de ansible.netcommon a aceitação de chave alterada com adição automática. A exploração exige interceptação e registro prévio; execuções padrão não interativas bloqueiam a conexão.
A CVE-2026-126641 orienta esta apuração. A decisão empresarial deve partir do job concreto que pode alcançar um equipamento. Escolha uma automação representativa, seu grupo de destinos e a equipe que responde pela mudança de rede. O roteiro abaixo é uma proposta de verificação autorizada, não uma afirmação de que seu ambiente sofreu interceptação ou de que todas as instalações estão expostas.
Descubra o que executou aquela conexão
Reúna o identificador do job, a imagem do ambiente de execução, as coleções instaladas, o transporte selecionado e a origem das configurações. Faça essa coleta no contexto efetivamente utilizado pelo controlador. Um arquivo revisado no computador do administrador pode ser apenas uma das entradas do processo. Identifique também quem consegue alterar cada entrada entre a revisão e a execução.
A divulgação original distingue ANSIBLE_LIBSSH_HOST_KEY_AUTO_ADD de ANSIBLE_HOST_KEY_AUTO_ADD do network_cli: esta última não é encaminhada ao transporte libssh.
Organize uma pequena tabela por grupo de ativos, com o transporte observado e a referência da configuração que o determinou. Marque como pendente um grupo cujo caminho de conexão não pôde ser confirmado. Use referências ao cofre para identificar credenciais autorizadas, sem copiar seus valores para a tabela ou para um relatório compartilhado.
Dê procedência à identidade aprovada
Para cada destino escolhido, solicite ao responsável do ativo uma referência de identidade aprovada por um canal previamente conhecido. Relacione essa confirmação ao nome, endereço e função do equipamento no inventário. A equipe deve conseguir explicar por que aceita aquela referência e quem tem autoridade para substituí-la, inclusive durante uma troca legítima de servidor.
Trate uma substituição planejada como mudança de ativo: registre a identidade anterior, a nova referência, a janela e a aprovação. Se surgir uma divergência inesperada, preserve o registro observado e encaminhe a investigação antes de autorizar outra execução. O aceite não deve depender de uma pessoa reconhecer visualmente um aviso durante uma tarefa urgente.
Ensaie a recusa sem usar segredos de produção
Em laboratório autorizado, apresente outra identidade no mesmo endereço. A divergência deve bloquear o avanço do job.
Defina esse resultado esperado antes do exercício e use contas e dados sintéticos. Registre onde a execução parou e quais arquivos ou registros foram produzidos. Confirme também que a evidência aceita pelo próximo job continua correspondendo à referência aprovada. Não transforme uma janela de produção em laboratório nem reutilize senhas reais para demonstrar uma falha.
O exercício deve incluir a passagem de turno: outra pessoa recebe apenas o chamado, as referências permitidas e os resultados. Peça que ela explique qual destino estava autorizado e por que a tarefa foi interrompida. Uma conclusão que depende de mensagens privadas do primeiro operador ainda precisa de documentação para sustentar a operação.
Vincule a próxima execução ao que foi aprovado
Depois da revisão, conserve um identificador da imagem de execução e das configurações examinadas. Combine quais alterações obrigam a repetir o ensaio: mudança de transporte, substituição do ambiente, alteração de inventário ou troca da referência de identidade. O dono da automação deve receber essas condições junto com a autorização para retomar os jobs delimitados.
A análise de OpenSSH no Alpine acompanha outro evento, voltado às contas e ao serviço de autenticação. Aqui, o critério proposto acompanha o destino aceito pela automação. Relacione os dois trabalhos no inventário, preservando o escopo e a evidência de cada avaliação.
Perguntas frequentes
Qual job deve entrar primeiro no roteiro?
Escolha uma automação com responsável definido, destinos conhecidos e ambiente reproduzível. Use essa amostra para esclarecer dependências antes de ampliar o escopo.
Uma troca legítima de servidor encerra a divergência?
Ela precisa de uma aprovação rastreável da nova identidade. Relacione a substituição ao ativo, à janela e à pessoa autorizada a aceitá-la.
O relatório deve conter as credenciais utilizadas?
Guarde identificadores e referências de acesso. Mantenha os valores das credenciais nos sistemas aprovados e limite quem recebe os registros técnicos.
Quando repetir a verificação?
Defina os gatilhos no aceite, incluindo mudanças no ambiente de execução e no caminho de conexão. Registre quem acompanha essas alterações e suas pendências.
Fontes e referências
Análise original da Pentesty, publicada em 13 de novembro de 2026. Os cenários propostos são orientações editoriais, com escopo e validação a definir para cada ambiente.