Ok, so I understand now.
Because we do not see it in known hosts AND you have host key checking enabled globally in Ansible but not disabled for these specific hosts, the locking code is anticipating a question from SSH will engage in anticipation of needing to block for these hosts.
The answer seemst o be making an inventory variable that allows disabling host key checking on a per inventory basis.
That sounds interesting. So that means modifying the ec2.py script to supply that variable, probably as an ec2.ini option? That could work. If the ec2.py output could be set to automatically disable host key checks for each host in my ec2 inventory, then I could still use host key checking for my small inventory of static hosts. That would be nice.
It wouldn’t be able to tell what your SSH client would do in advance, but could easily not check for that particular host.
I disagree entirely that --forks should be disabled with unknown host keys, as that’s simply not true – most users will just approve the hosts they need.
I don’t think I proposed anything of the kind. That isn’t what my crude patch does, either. The text of the message might be misleading: it’s telling you that --forks isn’t doing much of anything. But it isn’t changing the existing functionality at all.
What I’ve observed is that --forks doesn’t do any good if the hosts are unknown, and that it’s difficult to debug the problem if the prompts are disabled. When this happens I think the user should see what’s happening, and why. When users set --forks, I suspect they’re usually targeting hosts that they’ve already accepted - or as in my situation they don’t care about key checks. So it feels about right to display a warning when there are unknown hosts and --forks is set.
However, I’m ok with being able to turn them off for a particular group, which you could set for the ec2_tag_foo group.
For me those groups are also ephemeral. I’d want to disable host key checking for my entire ec2 inventory, probably as an option in ec2.ini.
I like this idea, but I don’t think it addresses the root problem. When host key checks happen, --forks is effectively ignored. Because this happens without any feedback to that effect, the problem is difficult to debug.
With this inventory variable idea, the ec2.ini default would probably be normal host key checking. So if someone like me sets up ssh_config to ignore amazonaws.com hosts, then the same problem will show up and will be just as difficult to track down. All commands will be serialized, and the user won’t have a clue why that’s happening.
What about a more generic message? A single line like “Checking host key for unknown host %s” would not add much noise on top of ordinary host-key acceptance, while still showing some visible sign of a problem when host-key storage is suppressed. If I had had that extra message logged even when I knew that I had customized ssh_config, I might have found the solution more quickly.
The downside, besides being less secure, is that ansible will not found the host in the known_hosts file. Fortunately, the ANSIBLE_HOST_KEY_CHECKING=no option works well to disable this feature.