Is it safe to disable SSH host key checking if key-based authentication is used?

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.

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:

• RFC 4252 7. Public Key Authentication Method
• RFC 4251 9.3.4. Man-in-the-middle

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.