When working with SSH ProxyJump (-J flag), many developers encounter unexpected host key verification behavior that appears to override explicit StrictHostKeyChecking=no settings. This becomes particularly frustrating when automating infrastructure provisioning or working with ephemeral environments.

The fundamental problem occurs because SSH performs two distinct connection phases when using ProxyJump:

1. First connection to the jump host (with your specified settings)
2. Second connection from jump host to target (where settings may not propagate)

To properly disable host key checking for both phases of ProxyJump connections, you need to configure these options in your SSH config file:

Host jumpbox
    HostName your.jumpbox.address
    User jumpuser
    IdentityFile ~/.ssh/id_jumpuser_rsa
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    GlobalKnownHostsFile /dev/null

Host 10.10.0.5
    HostName 10.10.0.5
    User targetuser
    ProxyJump jumpbox
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
    GlobalKnownHostsFile /dev/null

For one-time connections, this comprehensive command structure works reliably:

ssh -o "ProxyCommand ssh -W %h:%p \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -o GlobalKnownHostsFile=/dev/null \
    jumpuser@jumpbox" \
    -o StrictHostKeyChecking=no \
    -o UserKnownHostsFile=/dev/null \
    -o GlobalKnownHostsFile=/dev/null \
    targetuser@10.10.0.5

The solution addresses several subtle aspects of SSH behavior:

• GlobalKnownHostsFile prevents checking system-wide known_hosts
• Explicit settings in both connection phases ensure consistent behavior
• ProxyCommand offers more control than -J for complex scenarios

While disabling host key verification is sometimes necessary for automation, be aware that this:

• Opens potential MITM attack vectors
• Should only be used in controlled environments
• Can be combined with other security measures like certificate-based auth

---

When using SSH with ProxyJump (-J flag), many administrators encounter unexpected host key verification behavior that appears to override the StrictHostKeyChecking=no directive. The problem manifests specifically when:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null \
    -i ~/.ssh/id_jumpuser_rsa -J jumpuser@jumpbox jumpuser@10.10.0.5

The SSH client performs two distinct connection phases:

• Phase 1: Connection to jump host (jumpbox)
• Phase 2: Connection to target host (10.10.0.5)

Key observations:

1. Direct connections respect StrictHostKeyChecking as expected
2. ProxyJump connections enforce verification despite explicit directives
3. The warning references ~/.ssh/known_hosts of the LOCAL user

The OpenSSH implementation treats ProxyJump connections differently:

• The jump host connection uses the system's default known_hosts file
• Command-line parameters only apply to the final destination connection
• This behavior is hardcoded in the channel establishment logic

Method 1: Pre-populate known_hosts (recommended for production)

ssh-keyscan -H jumpbox >> ~/.ssh/known_hosts

Method 2: Configuration file approach

# ~/.ssh/config
Host jumpbox
    HostName jumpbox
    User jumpuser
    IdentityFile ~/.ssh/id_jumpuser_rsa
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Host 10.10.0.5
    HostName 10.10.0.5
    ProxyJump jumpbox
    User jumpuser
    IdentityFile ~/.ssh/id_jumpuser_rsa

Method 3: Environment variable override

SSH_KNOWN_HOSTS=/dev/null ssh -J jumpuser@jumpbox jumpuser@10.10.0.5

For automation scenarios, consider these approaches:

Option A: Temporary known_hosts file

TEMP_KNOWN_HOSTS=$(mktemp)
ssh-keyscan -H jumpbox > $TEMP_KNOWN_HOSTS 2>/dev/null
ssh -o UserKnownHostsFile=$TEMP_KNOWN_HOSTS -J jumpuser@jumpbox jumpuser@10.10.0.5
rm $TEMP_KNOWN_HOSTS

Option B: Custom SSH wrapper script

#!/bin/bash
clean_ssh() {
    local jump_host=$1
    shift
    ssh-keyscan -H $jump_host > /tmp/ssh_temp_known_hosts 2>/dev/null
    ssh -o UserKnownHostsFile=/tmp/ssh_temp_known_hosts "$@"
    rm /tmp/ssh_temp_known_hosts
}

While disabling host key verification solves immediate problems, consider:

• This creates potential MITM attack vectors
• Recommended for test environments only
• In production, always maintain proper host key verification
• Automated key management solutions are preferable

Behavior varies across OpenSSH versions:

• 7.3+ implements stricter ProxyJump verification
• 8.0+ allows some configuration flexibility
• Consider upgrading if using older versions