SSH Keys - A Lesson for the Future Me
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 ...."