Once again, this shows the strength of mutual authentication (ssh user key authentication, or HTTPS client certificates): even if the client accepts the forged server key from a MITM server, the real server won't accept the client key exchange (since it, at least in the SSH protocol, is bound to the connection). For the three things the attacker did here:

1. It can't steal your password, since the private key never leaves your client;

2. It can observe each command you type, but it can't open a connection to the real server to know how it would respond to your commands;

3. It can't open any connection to the real server (it will fail authentication), so it can't do anything to the real server.

If you really like passwords, there are ways to configure sshd to require both a client key and a password, in that order.

You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.

Or use fido/gpg in a yubikey - the user gets to authenticate the use of the secret, but it never leaves the hardware token, let alone the client computer.