21

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?

  • 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) – Adi 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. – Adi 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
15

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 not be 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:

  • 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. – Adi Aug 3 '13 at 15:30
  • 1
    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. – Adi Aug 5 '13 at 1:20
  • In your second scenario, even if the attacker managed to establish a session with your ssh client, wouldn't it be difficult for the attacker to simulate a completely identical setup to present to you? I mean, even if OS version and installed services may be pre-determined through information gathering, things like files in your home directory, command history and autocompletes, etc. would be hard to simulate without accessing the real ones, right? It does not help with security in theory I know, but it may deter attackers from attempting this kind of MITM in practice, I suppose? – zypA13510 Jun 28 at 2:13
4

It would be unsafe if you have SSH agent forwarding enabled in your configuration for the server in question.

If you use an SSH agent to manage your key-based authentication and you use ssh -A or if you have something like this in your ~/.ssh/config:

Host example.com
    ForwardAgent yes

or if you have ForwardAgent enabled globally, then it is not safe to skip or ignore the host key checks.

The accepted answer is excellent but omits this very important caveat.

With agent forwarding enabled, and assuming that your agent has the key to the server being MITMed, then the attacker can allow you to connect to it as described in the accepted answer, then make a new connection to the real server using the key from your forwarded agent. Most (all?) agents will silently allow this. And the result would be that now you have a fully MITMed connection to the real server.

In some ways, this is analogous to the password authentication MITM attack. In the password authentication scenario, the MITM steals your password and uses it to authenticate to the server so that you are none the wiser. In the public key authentication scenario (with agent forwarding), the attacker makes use of your agent to authenticate. So although the attacker would not gain possession of your key, the attacker could use your key via the agent to authenticate as you to the server, and also to impersonate you to other hosts that accept your key (but only for the duration of the session).

This scenario and the SSH agent hijacking scenario in the non-MITM case are the two reasons to be VERY careful about which hosts you forward your agent to. Think of everything that an attacker could do with access to the key(s) your agent has loaded. For example, if your workstation is configured to accept one of the keys, the attacker could ssh back to your workstation and retrieve the SSH private key. And if the private key has a passphrase, the attacker could install a keylogger and patiently wait until the next time you decrypt it.

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.