When connecting to a new SSH server for the first time, you'll encounter the infamous prompt:

The authenticity of host '10.x.x.x (10.x.x.x)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This security feature exists for good reason - to prevent man-in-the-middle attacks. However, in automation scenarios like CI/CD pipelines, container initialization, or remote server provisioning, this interactive prompt breaks non-interactive workflows.

The common attempt yes | ssh root@10.x.x.x fails because SSH specifically checks if stdin is a terminal and won't accept piped input for security reasons. The SSH client wants to ensure a human is making the trust decision.

The correct approach is to use SSH's configuration options:

ssh -o "StrictHostKeyChecking=no" root@10.x.x.x

Or add it to your SSH config file (~/.ssh/config):

Host *
    StrictHostKeyChecking no

While convenient, disabling host key checking completely removes MITM protection. For production environments, consider these safer alternatives:

Option 1: Pre-populate known_hosts

ssh-keyscan 10.x.x.x >> ~/.ssh/known_hosts
# Then connect normally:
ssh root@10.x.x.x

Option 2: Use hashed hostnames

ssh-keyscan -H 10.x.x.x >> ~/.ssh/known_hosts

Option 3: Specify the expected fingerprint

ssh -o "StrictHostKeyChecking=accept-new" \
    -o "UserKnownHostsFile=/dev/null" \
    root@10.x.x.x

Host my-production-server
    HostName 10.x.x.x
    User root
    StrictHostKeyChecking accept-new
    UserKnownHostsFile ~/.ssh/known_hosts_production

• Use accept-new instead of no when possible
• Maintain separate known_hosts files for different environments
• Consider using SSH certificates instead of host keys
• In CI/CD systems, cache the known_hosts file between runs

---

When connecting to a new SSH server, you typically see this security prompt:

The authenticity of host '10.x.x.x (10.x.x.x)' can't be established.
RSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is a critical security feature, but in automation scenarios or when managing infrastructure at scale, manual confirmation becomes impractical.

The common attempt yes | ssh root@10.x.x.x doesn't work because:

• SSH deliberately ignores piped input for security reasons
• The prompt is displayed on stderr, not stdout
• Interactive confirmation requires terminal input

Here are three robust methods to automate this process:

1. Using StrictHostKeyChecking Option

The most straightforward solution:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@10.x.x.x

This:

• Disables strict host key checking
• Prevents writing to known_hosts file
• Works for one-time connections

2. Pre-populating Known Hosts

For persistent connections, add the key beforehand:

ssh-keyscan -H 10.x.x.x >> ~/.ssh/known_hosts
ssh root@10.x.x.x

3. Using Expect Script

For complex automation scenarios:

#!/usr/bin/expect -f
spawn ssh root@10.x.x.x
expect "Are you sure"
send "yes\r"
interact

While convenient, these methods reduce security:

• Disabling host verification makes you vulnerable to MITM attacks
• Use in trusted networks only
• For production, prefer proper key management

For production environments:

# First collect the key properly
ssh-keyscan -H 10.x.x.x > /tmp/server_key
ssh-keygen -lf /tmp/server_key  # Verify fingerprint

# Then add to known_hosts
cat /tmp/server_key >> ~/.ssh/known_hosts

This maintains security while automating the process.