How to fix Someone could be eavesdropping on you right now (man-in-the-middle attack)! in SSH

SSHINTERMEDIATEHIGH

This warning appears when SSH detects that a server's host key has changed since your last connection. While it could indicate a real attack, it's often caused by legitimate server maintenance, reinstalls, or key rotations. Learn how to verify the change is legitimate and safely reconnect.

What this error means

SSH uses host keys—unique cryptographic identifiers for each server—to protect you from man-in-the-middle (MITM) attacks. When you first connect to a server, SSH saves its host key fingerprint in your ~/.ssh/known_hosts file. On subsequent connections, SSH verifies that the server's current key matches the stored fingerprint. If the keys don't match, SSH displays this warning because an attacker could be impersonating the server and intercepting your credentials and data. This is a critical security feature, but key changes can happen for legitimate reasons like server reinstalls, key rotations, or migrated infrastructure.

How to fix "Someone could be eavesdropping on you right now (man-in-the-middle attack)!"

1Stop and contact the server administrator immediately

Do NOT automatically accept the warning. First, verify that the server change was legitimate:

bash

# Your connection will fail. This is OK—it's protecting you.
ssh user@hostname

Contact the system administrator through a trusted out-of-band channel (phone call, verified email, corporate chat):
- "I got a man-in-the-middle attack warning for [hostname]. Did you recently reinstall or migrate this server?"
- "Can you provide the new server's SSH host key fingerprint?"

Only proceed if the administrator confirms the key change was intentional.

2Get the new host key fingerprint from a trusted source

Ask your administrator to provide the server's new SSH fingerprint through a secure channel:
- Printed in server console output during/after OS installation
- Available in cloud provider's dashboard (AWS Systems Manager, Azure Serial Console, etc.)
- Published on the organization's internal wiki or documentation

The fingerprint should look like:

bash

RSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdh.
ECDSA key fingerprint is SHA256:abcdef0123456789abcdef0123456789abc.
ED25519 key fingerprint is SHA256:xyz0123456789abcdefghijklmnopqrst.

Keep this fingerprint for the next step.

3Verify the fingerprint SSH shows you

Attempt to connect again and carefully compare the fingerprint SSH displays:

bash

ssh user@hostname

SSH will prompt:

bash

The authenticity of host 'hostname (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdh.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Compare the fingerprint shown with the one from your administrator. Character-by-character. Do not skip this step.
- If fingerprints match: Type yes to proceed.
- If fingerprints DON'T match: Type no and investigate further—this could indicate a real attack.

4Remove the old host key from known_hosts

After verifying the fingerprint is legitimate, remove the old key using ssh-keygen:

bash

ssh-keygen -R hostname
ssh-keygen -R 192.168.1.100

This removes all old keys (RSA, ECDSA, ED25519) for that host from ~/.ssh/known_hosts. You can run both commands if you want to remove keys for both the hostname and IP address.

Verify the old key was removed:

bash

grep -n hostname ~/.ssh/known_hosts
# Should show no results after removal

5Reconnect to save the new host key

Attempt to SSH to the host again. Since you just removed the old key, SSH will treat this as a fresh connection:

bash

ssh user@hostname

SSH will again ask if you want to add the host's fingerprint. This time you've already verified it, so type yes:

bash

The authenticity of host 'hostname (192.168.1.100)' can't be established.
ECDSA key fingerprint is SHA256:jksdhfkjsdhfkjsdhfkjsdhfkjsdhfkjsdh.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes

The new key is now added to ~/.ssh/known_hosts. Future connections won't prompt again.

6If SSH is used in automated deployments (CI/CD, Ansible, etc.)

If this error appears in your CI/CD pipeline or automation:

Option 1: Pre-populate known_hosts before deployment

bash

ssh-keyscan hostname >> ~/.ssh/known_hosts 2>/dev/null

This adds the host key without prompting. Use this in Docker images or deployment scripts.

Option 2: For GitHub/GitLab/Bitbucket
Most systems already have these services' keys in known_hosts. If not, add them explicitly:

bash

# Add GitHub
ssh-keyscan github.com >> ~/.ssh/known_hosts 2>/dev/null
# Add GitLab
ssh-keyscan gitlab.com >> ~/.ssh/known_hosts 2>/dev/null

Option 3: Accept only new keys (least risky for automation)

bash

ssh -o StrictHostKeyChecking=accept-new user@hostname

This accepts new host keys automatically but still verifies previously known keys. Available in OpenSSH 7.6+.

Advanced notes

Advanced security considerations:

How to Actually Detect a Real MITM Attack:
- If you've never connected to this host before, you can't know if it's being attacked unless you verify the fingerprint through a completely separate channel (phone call, in-person verification, official documentation)
- If you HAVE connected before and suddenly see this warning, this is a genuine red flag. Stop and contact the administrator through a different communication channel (phone, SMS, in-person)
- Attackers deliberately avoid intercepting traffic from clients that already have a known_hosts entry because it would trigger exactly this warning and alert you

SSH Host Key Verification Levels:
- StrictHostKeyChecking=yes (default): Refuse connections if key is unknown or changed—most secure, used for initial connections
- StrictHostKeyChecking=accept-new: Accept new keys automatically but verify known keys—good for automation
- StrictHostKeyChecking=no: Accept any key without verification—dangerous, disables MITM protection entirely, never use in production

Best Practices:
- Always verify fingerprints through an independent channel (not SSH, not email from the target host)
- Keep ~/.ssh/known_hosts backed up—it's useful when setting up new workstations
- In corporate environments, consider a SSH key management system or certificate-based authentication
- For Docker/Kubernetes: Build known_hosts into container images during the build process, not at runtime
- For Terraform/IaC: Use provisioners to populate known_hosts before running remote-exec provisioners

GitHub's 2023 Key Change:
In March 2023, GitHub reset their public SSH key due to a previous key being exposed. Many developers saw this exact warning. If it happens with a service you trust:
1. Check the official blog/status page
2. Verify the new fingerprint on their official site
3. Update known_hosts

This demonstrates that even major services undergo key rotation, making this warning a normal part of infrastructure maintenance.

How to fix Someone could be eavesdropping on you right now (man-in-the-middle attack)! in SSH

What this error means

Typical symptoms

Common causes

How to fix "Someone could be eavesdropping on you right now (man-in-the-middle attack)!"

Advanced notes

Related errors

Official resources & further reading