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?

Improve this question
10
  • Do you connect to the IP address directly or do you use a (dynamic) DNS record to determine the server's IP?
    – Manuel Faux
    Commented May 17, 2014 at 13:40
  • I use DDNS. Surely this wouldn't affect the server's public key fingerprint though?
    – toxefa
    Commented May 17, 2014 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
    Commented May 17, 2014 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.
    – toxefa
    Commented May 17, 2014 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
    Commented May 17, 2014 at 16:46

1 Answer 1

Reset to default
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).

Improve this answer
1
  • 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?
    – toxefa
    Commented May 17, 2014 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .