Getting Rid of the “WARNING: POSSIBLE DNS SPOOFING DETECTED!” Message When Connecting via SSH
Tags: linux, tech, ssh, knownhosts
Published: 2018-04-03 21:32:27

---
title: Getting Rid of the “WARNING: POSSIBLE DNS SPOOFING DETECTED!” Message When Connecting via SSH
published: true
description: 
tags: linux,tech,ssh,known_hosts
---
![Robot Cleaner](https://thepracticaldev.s3.amazonaws.com/i/f59tx79i71ltx6ehqhm2.jpg)

I came across this error when I was migrating servers. I tried to connect to one of the servers via SSH and then this appeared.

```
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for blog.dealdey.com has changed,
and the key for the corresponding IP address 176.31.35.20
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /Users/Macbook/.ssh/known_hosts:147
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:k+mijCohJm9g2pXglfmAgrvxWYqDtuzGO7do+Yt2Sd4.
Please contact your system administrator.
Add correct host key in /Users/Macbook/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/Macbook/.ssh/known_hosts:95
ECDSA host key for blog.dealdey.com has changed and you have requested strict checking.
Host key verification failed.
```

This warning came up because blog.dealdey.com now has a new IP address. The existing ECDSA (Elliptic Curve Digital Signature Algorithm) host key in the known_hosts file stored on my local machine was no longer valid for connection to the new server hence, a yellow flag was raised.

## The known_hosts file
When you connect to a server via SSH for the first time, the public key of the server is sent to your local machine and added to a list of known hosts stored in, you guessed it, the known_hosts file.

```
> ssh user@blog.dealdey.com
The authenticity of host 'blog.dealdey.com (176.31.35.18)' can't be established.
ECDSA key fingerprint is SHA256:exV5JiKkxDDh90/Bne5lRYWbpbX1al2KlNw0aO0hlcM.
Are you sure you want to continue connecting (yes/no)?
```

Responding with `yes` adds the host key to the list of known hosts.

```
Warning: Permanently added 'blog.dealdey.com' (ECDSA) to the list of known hosts.
```

For all subsequent connections to the server, the server is authenticated. The SSH client checks the known_hosts file to ensure that it is about to connect to the right server. If the SSH client detects any difference between the server host key and the key stored in the known_hosts file, the connection is prevented and the warning is displayed.

There are two ways to fix the warning.

### 1. Deleting the Old Host Keys
We can fix this issue by removing the offending (i.e existing) ECDSA key for the blog.dealdey.com from the known_hosts file on the specified line —  line 95.
Locate and open the known_hosts file on your local machine.
Delete line 95.
Connect to the server via SSH.

If the warning comes up again, delete the line specified in the warning. Once all the offending keys for the domain have been removed, a new host key for the new server will be added to the known_hosts file and you will be successfully connected to the server.

### 2. Using ssh-keygen
Another method is to use ssh-keygen to remove all the keys for the domain. Just run the command below. Be sure to replace path/to/known_hosts with the path to the known_hosts file on your local machine.

```
ssh-keygen -f "path/to/known_hosts" -R blog.dealdey.com
```

Connect to the server via SSH. A new host key for the new server will be added to the known_hosts file and you will be successfully connected to the server.

While both methods get the issue resolved, Method 2 is definitely much more efficient, faster and less error-prone than Method 1.

You can read more about DNS Spoofing here https://www.howtogeek.com/161808/htg-explains-what-is-dns-cache-poisoning/ and about ECDSA here https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm.