Struggling with automation hanging on SSH host key prompts? Learn why it happens and discover three solutions, from a quick-and-dirty fix to the proper, scalable approach for your Ansible playbooks or scripts.

I Saw Your “Help with Automation!” Post. Let’s Talk About That SSH Prompt.

It was 2 AM. We were rolling out a critical patch across our entire web fleet. The Ansible playbook was humming along nicely, instance by instance. Then, everything just… stopped. No errors, no explosions, just a deafening silence in the pipeline log. After 15 minutes of frantic digging, I found the culprit hanging on a single new server, `prod-web-78`, taunting me: Are you sure you want to continue connecting (yes/no/[fingerprint])?. The entire automated deployment was waiting for a human to type “yes”. I’ve been there, my friend. It’s an infuriating, classic “rite of passage” for anyone stepping into automation, and that Reddit thread brought it all back.

The Root of the Problem: It’s a Feature, Not a Bug

Before we fix it, let’s get one thing straight: SSH is not trying to ruin your day. This prompt is a critical security feature called host key verification. It’s designed to prevent Man-in-the-Middle (MITM) attacks. When your machine connects to a server for the first time, the server presents its public key “fingerprint”. By typing “yes”, you are telling your machine, “I trust this fingerprint and associate it with `prod-db-01` from now on.” This gets saved in your ~/.ssh/known_hosts file.

The problem is that our automation tools—be it Ansible, a Jenkins pipeline, or a simple bash script—are not people. They don’t have fingers to type “yes”. When they encounter this interactive prompt, they just hang, waiting for input that will never come.

The Fixes: From Duct Tape to Solid Engineering

Okay, enough theory. You need to get your pipeline running again. Here are three ways to handle this, ranging from “get it working now” to “do it right for the long haul.”

Solution 1: The Quick & Dirty Fix (The “YOLO” Flag)

You can tell your SSH client to just… not check. At all. This involves turning off StrictHostKeyChecking. It’s fast, easy, and generally a bad idea for production environments, but it can be a lifesaver for temporary, non-critical systems like build agents or dynamic test environments.

You can do this directly in your command:

ansible-playbook -i inventory.ini my_playbook.yml -e 'ansible_ssh_common_args="-o StrictHostKeyChecking=no"'

Or you can set it in your Ansible configuration file (ansible.cfg):

[defaults]
host_key_checking = False

A Word From The Trenches: Please, be careful with this. Disabling host key checking is like leaving your front door unlocked. It’s convenient until it’s not. Use this for ephemeral, low-risk environments where the servers are destroyed after the run. Never make this the default for your production bastion host.

Solution 2: The Permanent Fix (The “Do It Right” Method)

The correct way to solve this is to teach your machine about the new server’s host key before you try to connect. You automate the process of adding the key to the known_hosts file. The standard tool for this is ssh-keyscan.

Here’s how you can add a server’s key before running your main automation script:

# Target the new server, e.g., prod-db-01
TARGET_HOST="prod-db-01.techresolve.local"

# Scan the host's key and append it to the known_hosts file
ssh-keyscan -H ${TARGET_HOST} >> ~/.ssh/known_hosts

# Now your automation can connect without a prompt
ansible-playbook -i inventory.ini deploy_database.yml --limit ${TARGET_HOST}

In a more robust setup, you’d run this for a whole list of servers. For Ansible, we often have an initial “setup” playbook that does exactly this for all hosts defined in the inventory.

Solution 3: The ‘Nuclear’ Option (The Enterprise Way)

In large, dynamic environments where servers are constantly being created and destroyed, managing `known_hosts` can become a job in itself. The ultimate solution is to stop managing individual host keys and instead manage a central authority that signs them. This is done using an SSH Certificate Authority (CA).

Here’s the 10,000-foot view:

1. You create a central CA key pair.
2. You configure all your client machines (the ones running Ansible, etc.) to trust this CA.
3. When you provision a new server (`prod-api-112`), instead of just generating a standard host key, you have the CA sign that host key, creating a host certificate.
4. Now, when your client connects to the new server, the server presents its certificate. Your client sees it was signed by the trusted CA and immediately connects—no prompt, no `known_hosts` entry needed.

Setting up a CA with tools like ssh-keygen or HashiCorp Vault is more involved, but it’s the gold standard for security and scalability. It completely eliminates the host key verification problem at its source.

Choosing Your Path

So, which one is for you? Here’s how I break it down for my team:

Don’t let a simple prompt derail your automation. Understanding why it’s there is the first step. Picking the right tool for your scale and security posture is the next. Now go get that pipeline running.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions