4

UPDATE: The source of this problem has thankfully turned out to be a buggy mobile SSH client used on 2 different devices not a MITM attack. However, I'd still appreciate a full answer to the original question: Namely, in the event of a genuine MITM attack, what steps should an administrator take after detecting it? Does the presence of a genuine MITM attacker effectively make SSH access to that server impossible for as long as they attempt to intercept traffic? Is changing the sshd port sufficient as a response?

ORIGINAL QUESTION: I'd appreciate some advice on what steps I should take in dealing with this.

On attempting to connect to my home server today over SSH using pub key auth (password access is disabled), I received the 'fingerprint has changed' message. As I have a copy of the server's public key fingerprint on me, I can see they don't match.

Does this mean I am unable to connect to the server over SSH indefinitely without jeopardising security? Can I combat the attack in any way? While I've always been aware of the potential for SSH MITM attacks, and there is plenty of reading available on detecting such an attack, I cannot find any advice on countering / dealing with it once it's underway.

Thank you in advance.

UPDATE: The SSH host's public key and the copy I have are identical. But when connecting remotely (using either DDNS or direct IP), the 'Authenticity of host can't be established' message shows a different fingerprint to the server's. I need advice on how I connect to the server via SSH from now on in light of somebody potentially doing something nefarious. Do I simply change the SSH server port? Should I generate new keys?

  • Do you connect to the IP address directly or do you use a (dynamic) DNS record to determine the server's IP? – Manuel Faux May 17 '14 at 13:40
  • I use DDNS. Surely this wouldn't affect the server's public key fingerprint though? – py4on May 17 '14 at 13:56
  • No, it doesn't affect the server's fingerprint, but maybe the DNS record does not point to YOUR server right now, but to another SSH enabled server. I'd recommend to check that the IP you are connecting to is really the IP address the server is reachable under. – Manuel Faux May 17 '14 at 13:58
  • I've doubled checked this now and can confirm it points to the correct (the server's) WAN IP. I've shut down the machine until I have a solution whereby I can safely connect to the server remotely. – py4on May 17 '14 at 14:09
  • 3
    Where are you connecting from when you try to access it remotely? It may be worth trying a few variations, e.g. a friend's broadband, you mobile phone, etc. Perhaps only some are affected; perhaps all are affected. Either way, knowing the answer gets you closed to a solution. – paj28 May 17 '14 at 16:46
2

If you have physical access to the server, then log on its console and see if the server's public key has indeed changed. If it has changed, then try to work out why; if it has not, then this means that when you try to connect to your server with SSH you are actually talking to another machine, possibly because of an ongoing attack attempt, but more probably because of some routing or DNS misconfiguration.

For hosted servers, the provider should offer some IP-based KVM or rescue system which would be equivalent to physical access (in that context).

  • Thanks for the reply. I've logged in locally and can confirm that the host's public key fingerprint is different from the one presented each time I try to access it remotely. As the server is my own, I'd appreciate suggestions as to how to proceed now I'm aware of this. Is it sufficient to simply change the SSH port? – py4on May 17 '14 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.