I am trying to understand how a router NAT table modification might affect an SSH fingerprint.

The router is an infrastructure grade Mikrotik CCR1016-12G. I share that info only to emphasize that this is not a home network with a consumer router.

The affected server is a CentOS 7 container running on a Proxmox host. The container is on subnet X.X.91.0/24.

The IP address of the container server was not changed.

Monday I successfully logged into the container server using SSH.

Yesterday the NAT tables were changed on the router for that same 91 subnet.

Today, Wednesday, when I attempted to SSH into the affected server I received the standard SSH warning that the host key had changed. A direct login on that server showed that no keys were modified. Backups confirmed no such changes.

The only change in between the two SSH logins was the NAT tables on the router.

How does a NAT table change affect an SSH fingerprint?

Thanks much.

Mods: move this to the networking forum if appropriate.

In the known_hosts file under ~<user>/.ssh it includes the name and/or IP along with the key. If the NAT changed the IP the target user sees the originating user coming from it may be that which caused it to see the change.

I understand the known_hosts file entries. The puzzle here is the IP address and hostname have not changed. At least not in an obvious way. That is, I am still trying to SSH into X.X.91.X using the same hostname. Yet SSH says the fingerprint is different. I do not believe there is a true MIM attack, especially when I know about the NAT table changes. I just don't understand how the NAT table changes alters the fingerprint.

What MensaWater is saying is that if the IP or hostname of the local server has changed, or appears to have changed to the remote server, then the fingerprint needs to be re-established.

1 members found this post helpful.

NAT = Network Address Translation

That means when it sees the traffic come in on one address it can change it to show it came in on a different address. That original "different" address may be what your target user's known_hosts file stored as IP rather than the actual IP of the source machine. You said the NAT changed so that made me suspect the "different" address seen by the target user now that doesn't match what it used to be.

You can view the target's known_host file to see what it expects. You can delete the old entry from known_hosts on the target user so it just prompts you to accept a new fingerprint when you next attach from the source.

Ha. This turned out to be a classic red herring, where one issue masked another.

There was indeed some NAT table updates to the router. In hindsight the NAT changes were unrelated. Only that at the time, those NAT changes were the only obvious change that coincided with the server access failure.

The true problem happened earlier in the day. The IP address for the problematic server had been inadvertently added to the router's IP address list (on a Mikrotik RouterOS: IP->Addresses). Basically, the IP address assigned to the server was then owned by the router. Any attempt to remotely access the server was actually going to the router.

I discovered this by looking at the router log. I noticed a bunch of login attempts with date stamps coinciding with when I tried to SSH into the server. Removing the inadvertent addition resolved the issue.

The actual root cause was an IP address reassignment that, with respect to the overall time line, seemed related to the NAT table additions but actually wasn't.

The inadvertent addition was nothing more than an honest boo-boo -- filed under "lessons learned" by those involved.

1 members found this post helpful.