Assume the following scenario and please correct me if I am wrong somewhere:
There is a client and there is an SSH server that the client connects to. There is also a man-in-the-middle (MIM) which is able to intercept the client's incoming and outgoing traffic.
Now suppose that the client connects to the SSH server for the very first time and the server's public key info is not in the known_hosts file yet. The server sends its public key to the client, the client checks known_hosts file, does not find the server's public key there and hence the server now needs to prove its identity to the client. Identity is successfully proven (by using server's private key), but suppose that the client does not store the server's public key in the known_hosts after that (it is not mandatory to store it in the known_hosts, as far as I know).
The next time when client connects to the SSH server, the man-in-the-middle (MIM) intercepts client's connection request, and sends its own public key to the client, on behalf of the real SSH server. The client receives MIM's public key, inspects known_hosts file, and does not find the received public key in that file, so the "server" (MIM) needs to prove its identity again. Because the MIM's public key is associated with the corresponding private key, MIM successfully proves its identity to the client.
Is it possible to compromise security in that way? Correct me if I'm wrong somewhere please.
Someone told me that the server domain certificate is able to solve the problem, so additionally I would like to understand the purpose of host certificates. I have read that the certificate is put into known_hosts file just as the usual public key. But what's the point of using a certificate if we may use the same public key on all servers in domain, and simply put that public key into client's known_hosts file? Apparently, if there's no public key in known_hosts yet, the attack I've described above is still possible, and it doesn't matter whether the server uses certificate or not.