From 776722d95c116e4cf69b7b5d8e275798dafc6559 Mon Sep 17 00:00:00 2001 From: Konstantin Renner Date: Mon, 6 Jul 2026 08:35:14 +0200 Subject: [PATCH] =?UTF-8?q?ansible:=20Hostkey-Pr=C3=BCfung=20wieder=20akti?= =?UTF-8?q?vieren?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit host_key_checking=False entfernt (zurück auf Default = aktiv) und im Kommentar festgehalten, warum das nie wieder abgeschaltet werden darf: Der DNS-Drift-Vorfall vom 2026-07-06 (edge-1.iot.renner.uno zeigte per public Wildcard auf den Hetzner-Proxy) wurde nur deshalb nicht vom Hostkey-Wechsel-Alarm gestoppt, weil diese Einstellung ihn unterdrückt hat — ein Produktions-Play lief dadurch gegen die falsche Maschine. Co-Authored-By: Claude Fable 5 --- ansible/ansible.cfg | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ansible/ansible.cfg b/ansible/ansible.cfg index 9eb66ecf..067c03be 100644 --- a/ansible/ansible.cfg +++ b/ansible/ansible.cfg @@ -317,7 +317,12 @@ vault_password_file=~/source/homelab/ansible/vault-password.sh ;facts_modules=smart # (boolean) Set this to "False" if you want to avoid host key checking by the underlying tools Ansible uses to connect to the host -host_key_checking=False +# NIEMALS auf False setzen: Am 2026-07-06 hat genau diese Einstellung einen +# Produktions-Deploy auf die falsche Maschine durchgewunken (DNS-Drift: +# edge-1.iot zeigte auf den Hetzner-Proxy) — der Hostkey-Wechsel-Alarm war +# der einzige Schutz und wurde unterdrückt. Bei Hostkey-Fehlern: Ursache +# klären und known_hosts pflegen, nicht die Prüfung abschalten. +;host_key_checking=True # (boolean) Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace. # Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix. -- 2.54.0