When I ssh from one system to another on my own network, or between virtual machines, I usually don’t pay much attention to these warnings:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

since I know no one is meddling with my network and I know that’s the result of me reinstalling VMs or reusing IPs etc.

But when I see that while trying to log in to a remote VPS, which I know has been running for a long time without changing either name, ip, or SSH host keys, then I DO WORRY. And that happened to me this very morning, when attempting a login from my laptop.

I’m too much of a nobody to be the target of any hacking, but still, I need to know why I’m getting that warning before I can continue and log in. Thinking “nah, that’s probably nothing” is surely what happens right before you’re hacked for real.

My first step was to try to ssh from a different network and that worked without warning, which was a good sign, regarding my VPS, but it meant that either my ~/.ssh/known_hosts had something weird or I was indeed being attacked, however unlikely.

So all I had left was to think hard and try to remember precisely all I had done since the last time I logged in “warning-free”. And I found the real reason in my bash history:

ssh ateijelo@vps1.example.com -o "ProxyCommand proxytunnel -d vps2.example.com:443 ...."

That was it. I tried to get to vps1 through a restrictive http proxy by using a second server (vps2) that had ssh listening on port 443. And usually, when doing that, I paid little attention to what I wrote after my username ateijelo@... in the command line, since that wouldn’t dictate how to get to the server. It would be the ProxyCommand that took care of it.

But I learned today that what you write there does matter. It determines what gets written to ~/.ssh/known_hosts and in this case it ended up associating the host key of vps2 to vps1. The right thing to do is simple: make sure the hostname in the ssh command matches the destination of the proxy tunnel. Like this:

ssh ateijelo@vps2.example.com -o "ProxyCommand proxytunnel -d vps2.example.com:443 ...."