Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have some tasks that go like so:

  1. Spin up some new EC2 instances (Amazon Web Services)
  2. Get them to execute a task
  3. Kill them

The problem is that they're (seemingly) randomly assigned an IP address, and by chance a new machine reused an address that had previously been used.

This obviously lead to the following error, and my script failed:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is 
Please contact your system administrator.
Add correct host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/ec2-user/.ssh/known_hosts:595
RSA host key for 127.0.0.1 has changed and you have requested strict checking.
Host key verification failed.

I'm using a keypair when connecting to these machines, rather than using password authentication. Would this prevent a man-in-the-middle attack, since an attacker would not have the same keypair?

Am I safe to disable SSH host key checking?

share|improve this question
    
Are you sure that's what is happening? AFAIK, if you're using the IP to connect with your SSH client (i.e. ssh user@IP) then the new IP shouldn't freak out the SSH client like that, it should simply ask you to create a new entry (just like the first time you connected). That message effectively means that the server's public key was changed. In OpenSSH, the fingerprint is simply the an SHA-1 of the server's public key. (Note: I could be wrong here, this is just my interpretation of the specs) –  Adnan Aug 3 '13 at 15:34
    
@Adnan The problem case here isn't with a new IP address. The problem is a new server accessed through a repeat IP. (For example, Amazon assigns your first VM some IP; after you destroy it, a future VM you create may be given the same IP address, but the new VM will have a new keypair.) –  apsillers Aug 3 '13 at 23:54
    
@apsillers I'm fully aware of that. Please read my comment under my answer. I'm expressed my suspicion that the OP is misrepresenting his problem. –  Adnan Aug 4 '13 at 0:00
    
@Adnan Just to speak from personal experience, I've seen that error message many times when connecting to different machines that used the same dynamically-assigned IP on a local network (e.g., my SheevaPlug was 192.168.1.101 yesterday, but today that address refers to my laptop), which seems to be a direct analogue to what the OP is doing here. From tthat experience I personally don't find anything suspicious, but -- having read your comment below -- I can see how your reading of the spec would make you suspect misrepresentation. –  apsillers Aug 4 '13 at 0:42
    
@Adnan I'm sure that this is what's happening. I ran a quick test just to be 100% sure - I created an instance and assigned an Elastic IP address to it. After connecting to that instance, I killed it and created a new one, assigning the same IP address as the previous one. This caused the error above. –  Dean Aug 4 '13 at 4:46

1 Answer 1

up vote 10 down vote accepted

Short answer: Yes and no.

First of all, let's get things straight. How does key-based authentication work in SSH anyway? Once the SSH connection reaches the authentication phase, the client signs a bunch of data (this includes the session identifier) with its private key, then sends the signature to the server to verify it.

Signature verification pass -> Authentication successful.

How does a MiTM attack in this case then? The attacker sits between you and the server. For a successful attack he needs you to start a session with him, and he needs to start a session with the server. Whatever you send to the server, will actually go to him and he has the ability to modify it and send it to the server, and whatever the server sends you will actually go to the attacker and the attacker can modify it and send it to you.

Have you noticed something interesting? There are two sessions here (keep this in your mind). Each session is going to have its own session identifier because the generation of the session identifier isn't determined by the server or the client alone. In other words, the signature you use to authentication to the attacker will be different from the signature the attacker has to use to authenticate to the real server.

The attacker doesn't have the client's private key, meaning it won't be able to come up with a signature that the real server will accept. That's why this kind of full MiTM will is not possible.

MiTM SSH

So it's safe to disable host key/fingerprint checking, right? Not exactly. It's true that because the attacker won't be able to authenticate to the server, he won't be able to execute malicious commands on it. BUT

Remember when I told you about the two sessions? The attacker won't be able to establish session with the real server, but he can easily make you establish a session with him. The attacker will simply accept whatever signature you give him and trick you into thinking that you're now connected to the real server. You'll send him commands (and possibly some process-specific passwords) and he'll happily reply with whatever makes you happy.

Granted, there's no real danger to the server here since those commands aren't really reaching the server. It's just that there's no telling what you'll actually be sending the server (now the attacker). You might send keys, passwords (think, when you modify your password the server will ask you for the current password), and other sensitive information.

Bottom line is: If you're willing to accept the risk of connecting to a fake server that will know what you're sending to the real server, then disable host key/fingerprint checking. Otherwise, keep it enabled.

References:

share|improve this answer
1  
Is there a way to have the ssh client check that peer keys are one of a trusted set, but ignore IP addresses? –  Michael Aug 3 '13 at 13:33
1  
@Michael AFAIK, the host key in OpenSSH is simply an SHA-1 of the server's public key. The checking is done by the client by comparing the hostname-fingerprint pair. From what I see in the documentation, changing the IP doesn't invalidate fingerprint unless you're connecting using the IP, then the new IP should be a new fingerprint entry in the client's cache (because IP is now, loosely speaking, the hostname in the hostname-fingerprint pair stored by the client). I believe that the OP is misrepresenting/misdiagnosing the issue. –  Adnan Aug 3 '13 at 15:30
    
Just to clarify - from your answer it sounds like key-based client authentication behaves no differently from password-based client authentication. Is that correct? –  Dean Aug 5 '13 at 1:17
    
@Dean Not at all. If you disable host checking for password-based client authentication, then you're open to full MiTM attack. –  Adnan Aug 5 '13 at 1:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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